I am setup to use logback with my SpringBoot application and everything is running fine and dandy.
I noticed a property called logging.path in the application.properties file which sets the value for ${LOG_PATH} in logback.xml. How does it do it?
I went through the SpringBoot logging documentation.
Any documentation I could find on property placeholder configurer
Yet I don't understand how logging.path could pass the value for ${LOG_PATH}. Though not a killer issue, I would like to know how this mapping is made.
The magic is spring will transfter logging.path into System propeties LOG_PATH.
Description from spring doc:
To help with the customization some other properties are transferred from the Spring Environment to System properties:
And it also says:
All the logging systems supported can consult System properties when parsing their configuration files. See the default configurations in spring-boot.jar for examples.
Details:
https://docs.spring.io/spring-boot/docs/1.5.6.RELEASE/reference/htmlsingle/#boot-features-custom-log-configuration
For more recent versions of Spring Boot, such as 2.5.x, the logging.file.path maps to LOG_PATH.
Related
Currently spring boot seems to support only classpath based logging configuration.
It also ignores any configuration passed as vm argument as follows.
-Dlog4j.configurationFile=/opt/xyz/log4j2-prod.xml
How can we have different log4j2 configuration based on different environment, considering classpath for all environment remains same.
What about set the properties: logging.config=classpath:log4j2-dev-spring.xml in each application-{profile}.properties that you have. Can use like this too: logging.config=${ENV_VAR}
You should use the following param
-Dlogging.config='/path/to/log4j2.xml'
I am using log4j2 in my spring boot application. This works in all respects re: excluding slf4j, including log4j2, etc.
But when the application deploys I need to customize the file for each target host. I have created an ansible role that does this. Ultimately I end up with a log4j2.xml file deployed in another directory e.g. /prod/produsrX/data/log4j2.xml.
I am using the spring-boot-maven-plugin "repackage" goal to generate an executable jar file. It doesn't seem like that should matter but it is a data point in the problem.
This was supposed to be the easiest part of the project. Always before I have just been able to set -Dlog4j.configurationFile - advice which is echoed on about 3,000 web pages and DOES NOT WORK in Spring Boot 2.1.3.
The most useful info I've found is this question. It talks about using -Dlogging.config because logging must be initialized before other properties are read. Unfortunately that didn't help either.
I did find one example that suggested specifying the above directory in a -classpath parameter to java. But that didn't help either.
Does anyone know how to get a spring boot application to read the log4j2.xml file?
The property actually has to be put into the application context (e.g. application.yml). Using a -D property does not work!
logging:
config: /prod/produsrX/data/log4j2.xml #fully qualified name to your log4j.xml
I would like to change the logging level of my Quarkus application.
How can I do that either from the configuration file or at runtime?
The property that controls the root logging level is quarkus.log.level (and defaults to INFO).
This property can be set either in application.properties or can be overridden at runtime using -Dquarkus.log.level=DEBUG.
You can also specify more fine grained logging using quarkus.log.category.
For example for RESTEasy you could set:
quarkus.log.category."org.jboss.resteasy".level=DEBUG
For more information about logging in Quarkus, please check this guide.
I have set up my log configuration using logback.
The configuration sets up my logs in a rolling manner in a custom location. This means that I'm not using either:
"logging.file" or "logging.path" in my application.yml configuration, and as a consequence, the logfile endpoint no longer works.
Does anybody know of a way to customize this endpoint, so that I can point to the location/file specified in my logback.xml configuration?
Reading the two sections on Logging 26 & 74. It looks like it recommends using the logback-spring.xml config file with the base.xml configuration. With that you can still use the logging.file or logging.path application properties within the configuration. That way the /logfile endpoint is still valid for the current log file (probably won't look into the rolling files if that is what you setup).
You can specify the log file source from which the actuator will read.
To do that, try to use this property in your application.properties
endpoints.logfile.external-file=/var/log/app.log
or (based on your springboot version):
management.endpoint.logfile.external-file=/var/log/app.log
I am looking at externalizing certain configuration parameters for ehcache in our Grails application and I am running into something not working that the documentation claims ought to.
Likely there is something I am missing.
I am using the grails ehcache plugin version 1.0.1 with Grails 2.4.0 and grails cache plugin 1.1.7. I am using hibernate plugin 3.6.10.16.
Here's what I have in my CacheConfig.groovy configuration...
...
cacheManagerPeerProviderFactory {
peerDiscovery 'automatic'
factoryType 'rmi'
multicastGroupAddress '${ehcacheMulticastGroupAddress}'
multicastGroupPort '${ehcacheMulticastGroupPort}'
timeToLive 'site'
}
I've turned on debug-level logging so I can see what XML it generates. Here's the relevant snippet:
<cacheManagerPeerProviderFactory class='net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory'
properties="peerDiscovery=automatic,multicastGroupAddress=${ehcacheMulticastGroupAddress},multicastGroupPort=${ehcacheMulticastGroupPort},timeToLive=32"
propertySeparator=','
/>
The grails ehcache plugin documentation has the following note, which I was hoping to "prove out"...
(note that ${ehcacheMulticastGroupAddress} and ${ehcacheMulticastGroupPort} are an Ehcache feature that lets you use system property names as variables to be resolved at runtime)
Great. Except that it doesn't work when I start the application. It fails to create CacheManagerPeerProvider due to the following
...
Caused by UnknownHostException: ${ehcacheMulticastGroupAddress}
->> 901 | lookupAllHostAddr in java.net.InetAddress$1
...
I have a myApplication-config.groovy file living in an accessible area that I point to when assigning a value to grails.config.locations in Config.groovy. But I am not sure it is making any effort to really interpolate that value at all.
I tried double quotes but they were a bad idea as well -- at the time of interpreting CacheConfig.groovy it doesn't see the configuration I put into myApplication-config.groovy. I do know it reads that file in successfully at some point because I successfully use it to drive some Quartz job logic, so the placement of that config file is probably not the issue.
The answer is that I need to set SYSTEM PROPERTIES for ehcache to find. Using Grails configuration files such as myApplication-config.groovy is completely incorrect.
The CacheConfig.groovy file is correct, as is the XML it generates. So the question becomes, how do the properties it looks for get set correctly in the first place?
I am deploying to Tomcat. For Tomcat, setting system properties makes the most sense in a setenv.bat file (or setenv.sh on *nix).
I created setenv.bat, put the following into it
set CATALINA_OPTS=%CATALINA_OPTS% -DehcacheMulticastGroupAddress=230.0.0.1 -DehcacheMulticastGroupPort=4446 -DehcachePeerListenerPort=40001
...And it worked. Ehcache was able to find the system properties and start everything appropriately.
tl;dr: system properties != grails application config