Issues Defining Loggers in Application.cfc

Jamie_Bliss · July 3, 2025, 4:06pm

Hi all,

We’re running into a persistent issue with Lucee on Azure and would appreciate any insights.

The Problem: Almost daily, we lose all Lucee configuration data and logs. This includes critical settings like our database connection, which causes the site to go down until we reconfigure.

Our Workaround: To keep the site running, we moved the DB connection setup into the application.cfc file itself—this works well and survives the resets.

What We’re Trying to Do: To diagnose the root cause, we wanted to enable persistent logging. We found that Lucee supports logging directly to a database, which is perfect for our needs.

We successfully configured this via the Lucee Admin interface, that config will get lost during the next reset as well as the log files.

What We Tried: We attempted to define the DB logger in:

CFConfig.json
Application.cfc (similar to how we define the DB connection)
- an example of the config used

<cfset this.loggers["dberrorlog"] = {
   appender: "datasource",
   appenderArguments: {
   	datasource: "db name here",
   	tablename: "table name here",
   },
   level: "error"
}>

And then we call cflog like this

<cflog log="dberrorlog" type="error" exception="#arguments.error#">

But both approaches result in this error

What We Need Help With:

Has anyone successfully configured DB logging in Lucee using CFConfig.json or Application.cfc?
Are there best practices for persisting Lucee config in Azure environments?
Any ideas why the config and logs are being wiped daily?

Thanks in advance for any help or suggestions!

Zackster · July 3, 2025, 4:58pm

I have seen this randomly locally, my theory is that sometimes if there’s an error with the config, it can be somehow corrupted and gets discarded / reset.

github.com

lucee/Lucee/blob/6.2/core/src/main/java/lucee/runtime/config/ConfigFactory.java#L232


      
          		catch (Exception e) {
          			// rename buggy config files
          			if (configFile.exists()) {
          				Resource bugFile;
          				int count = 1;
          				Resource configDir = configFile.getParentResource();
          				while ((bugFile = configDir.getRealResource("lucee-" + type + "." + (count++) + ".buggy")).exists()) {
          				}
          
          				LogUtil.log(ThreadLocalPageContext.getConfig(), Log.LEVEL_INFO, ConfigFactory.class.getName(),
          						"The configuration file [" + configFile
          								+ "] contained syntax errors and could not be read. A new configuration file has been created, and the invalid file has been renamed to [" + bugFile
          								+ "].");
          				LogUtil.log(ThreadLocalPageContext.get(), ConfigFactory.class.getName(), e);
          
          				IOUtil.copy(configFile, bugFile);
          				configFile.delete();
          			}
          			createConfigFile(type, configFile);
          			return loadDocument(configFile);
          		}

From memory, it’s happened whilst doing some torture debugging/stress testing config stuff locally with Lucee, but that should never ever be happening.

Almost daily… is there any pattern to the problem?

Do you have code changing the Lucee configuration, either via configimport() or via the cfadmin tag?

By logs you mean the configured logs, rather than the actual files?

I’m not sure where you got this.loggers from (edit: that’s the key name in CFConfig.json), for Application.cfc it’s this.logs, you can verify your runtime configuration by dumping out getApplicationSettings()

Do you see anything in the out.log or err.log files under \tomcat\lucee-server\context\logs, they are the fallback logs when stuff goes badly wrong or before the normal logs are initialized

Also, what version of Lucee are you running?

Julian_Halliwell · July 4, 2025, 9:39am

Which Azure service are you using to run your Lucee instance(s)? VM or container?

Jamie_Bliss · July 4, 2025, 3:59pm

Starting with the easy questions, Lucee version is 5.4.6.9 and I am running it in a Azure Web App with the following configuration:

Stack: Java 11
Java Web Server: Apache Tomcat 9.0.54

And we only run one instance of the site.

Resource Usage

We’ve recently started digging deeper into some stability issues, after pushing a DB fix to prevent site crashes. I’ve been monitoring CPU and memory usage and, as shown in the screenshots below, the system is under very little stress—averaging around 50% memory usage and low CPU utilization:

To validate the metrics, I ran a basic test by hitting the site a few times per second from my local machine. This briefly maxed out the CPU for about a minute, but the site remained stable. The only noticeable impact was a slight increase in response times, which I suspect was mitigated by the Azure load balancer.

Logging Issues

I have also tried this.logs in Application.cfc but this instead of an error it gave me a white screen. I was able to find the below error in the tomcat logs

"ERROR","http-nio-80-exec-2","07/04/2025","16:16:08","controller","java.lang.NullPointerException;java.lang.NullPointerException
	at lucee.commons.io.log.log4j2.Log4j2Engine.layoutClassDefintion(Log4j2Engine.java:154)
	at lucee.runtime.listener.ApplicationContextSupport.initLog(ApplicationContextSupport.java:335)
	at lucee.runtime.listener.ModernApplicationContext.initLog(ModernApplicationContext.java:1761)
	at lucee.runtime.listener.ModernApplicationContext.getLog(ModernApplicationContext.java:1735)
	at lucee.runtime.PageContextImpl.getLog(PageContextImpl.java:3775)
	at lucee.runtime.engine.ThreadLocalPageContext.getLog(ThreadLocalPageContext.java:173)
	at lucee.runtime.exp.ExceptionHandler.log(ExceptionHandler.java:37)
	at lucee.runtime.PageContextImpl.handlePageException(PageContextImpl.java:2057)
	at lucee.runtime.PageContextImpl.handlePageException(PageContextImpl.java:2030)
	at lucee.runtime.listener.ModernAppListener.onError(ModernAppListener.java:439)
	at lucee.runtime.listener.MixedAppListener.onError(MixedAppListener.java:138)
	at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2522)
	at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2479)
	at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2450)
	at lucee.runtime.engine.Request.exe(Request.java:45)
	at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1215)
	at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1161)
	at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:97)
	at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51)

Which I didn’t really understand why it was a null pointer exception?!

Tomact Logs

Good shout for checking this, I don’t get an out.log or err.log I instead get catalina.hash.year-month-day.log. I have checked them on a known failure day but it was what looks like normal start up logs. There are two common warnings

18-Jun-2025 02:49:05.411 WARNING [main] org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with directory [C:\home\tomcat\lib], exists: [false], isDirectory: [false], canRead: [false]
18-Jun-2025 02:49:05.426 WARNING [main] org.apache.catalina.startup.ClassLoaderFactory.validateFile Problem with directory [C:\home\site\libs], exists: [false], isDirectory: [false], canRead: [false]

but as the server starts up I didn’t think it was an issue.