I have successfully migrated our application from log4j 1.x to log4j 2.x.
But there is one external component which cannot be migrated. Meaning calls to log4j 1.x should remain as they are.
I have log4j2.xml for our application and the old log4j.properties for the external component.I am getting the logs for the appenders in log4j2.xml but nothing for the one defined in log4j.properties. I read the post -
Mixing log4j 1.x and log4j 2
and have added the required jars. Earlier with log4j 1.x we used to have 2 log4j.properties - one for the applciation and another one for the external component using PropertyConfigurator. Now with log4j2.xml I am not sure how we can achieve this.
Configuring log4j2 and log4j using a single log4j2 xml file
This post says we cannot have log4j.properties in the classpath. Does that mean that I need to transfer all the appenders defined in log4j.properties to log4j2.xml ? Can I have a seperate log4j2.xml just for the external component.
You cannot have two log4j2.xml configurations (well, separate web apps can have separate configurations but in general each process has one config).
Option 1: The easiest thing to do is to use the bridge log4j-1.2-api-2.x.jar and merge the log4j.properties configuration into the log4j2.xml. Then all logging is done by lo4j 2 and it should all work.
If you want to do things the hard way you may be able to succeed but it may take some fiddling.
Option 2: If by "migrated our application from log4j 1.x to log4j 2.x" you mean your application now uses the log4j 2 API, then you should be able to use both log4j 1.x to log4j 2 at the same time. (log4j 1.x for the external component.)
In that case, do not use the bridge log4j-1.2-api-2.x.jar. If you use the bridge, it will route calls to the log4j 1.x API to log4j 2. Usually that is what you want, but in this case it sounds like your external component wants to use the log4j 1.x internals. (Is this true? If not, consider option 1.)
If your application now uses the log4j 2 API, except for the external component, then put these jars and config files in your classpath:
log4j-api-2.x.jar
log4j-core-2.x.jar
log4j-1.2.x.jar
log4j2.xml - the log4j 2 configuration for your application
log4j.properties - the log4j 1.x configuration for the external component
But again, simply merging the configurations is probably easier to maintain.
Related
I'm using Log4j2(2.17.1) with two type of configs(log4j.prop & log4j2.xml) on multiple projects. My APP's log4j2 works properly on Tomcat 9 while reading external log4j config. But somehow it stops working or only logging into server.log when I deploy my APP onto JBoss EAP 7. So I think the problem is coming from JBoss, and I need a way to tell it don't mess with my own Log4j2. Does anyone know how to do it?
With JBoss EAP 7.4 there is a new module which delegates the log4j-api logs to the jboss-logmanager. If you want to use the log4j log manager (log4j-core) then you need to exclude some modules from your deployment.
Option 1 below I would say is preferred since it only affects a single deployment. Option 2 will affect all deployments.
Option 1
Add a jboss-deployment-structure.xml to your deployment:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.apache.logging.log4j.api" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Option 2
Change the add-logging-api-dependencies attribute in the logging subsystem to false.
CLI example:
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)
The root cause for this issue is related to the "ClassLoader" which is searched by JBoss EAP Logging in order to find the appropriate logging provider implementation. This search is made in the following order:
JBoss EAP LogManager
Log4j
Slf4j
JDK logging
Since both JBoss EAP LogManager and Log4j2 are available in the classpath, the JBoss EAP LogManager will be utilized due to the "higher precedence". For this reason, you must set the use-deployment-logging-config=false in the logging subsystem.
Furthermore, the JBoss EAP LogManager also uses classes from Log4j2 in its own implementation. That's why the modules, org.apache.log4j and org.apache.commons.logging have to be excluded from the deployment in order for Log4J2 to work correctly.
I have a java application deployed on tomcat 9+. I am aware how to change the default tomcat logging to instead use log4j2.
I have done this by following this https://logging.apache.org/log4j/2.x/log4j-appserver/index.html.
I wanted to know rather than changing the default tomcat logging to use log4j2 is it possible to use log4j2 only for my war file without changing the code. My application has used JUL for logging purpose.
These days almost any logging configuration is possible.
Tomcat uses a special JUL LogManager (cf. ClassLoaderLogManager) that allows to specify a different JUL configuration in every application.
To redirect all JUL logs from your application to Log4j2 the easiest way is to pass through SLF4j. To do this:
Add jul-to-slf4j and slf4j-api to your project,
Add a WEB-INF/classes/logging.properties configuration file that redirects everything to the SLF4JBridgeHandler:
handlers = org.slf4j.bridge.SLF4JBridgeHandler
.handlers = org.slf4j.bridge.SLF4JBridgeHandler
Add the Log4j 2.x dependencies to your project: log4j-core, log4j-api and log4j-web and the SLF4j binding log4j-slf4j-impl.
Configure Log4j 2.x as you wish.
Warning: There is a performance penalty in this solution (cf. SLF4j documentation).
I am writing an application in Spring to be deployed to a Cloudfoundry container and want to override the default tomcat session timeout value from the Java buildpack. What are the options available to me if I want it to be a configurable value outside my code? i.e. avoid the use of HttpSession.setMaxInactiveInterval(int).
set-env JAVA_OPTS -Dserver.session.timeout=30
some way in application properties?
It sounds like you are using Spring Boot. If so, you could set server.session.timeout=30 in an application.properties file that gets included with your app. This file is usually in /src/main/resources in the source tree and is bundled into the jar file at build time.
I've externalized the properties file for my production Grails app running on Tomcat.
I'm wondering if there is a way the Grails app will read the configs from the config file in real time instead of having the changes take affect only after server restart.
For example, I'm using the LDAP plugin which has the following config:
grails.plugin.springsecurity.ldap.context.managerDn = 'somethinghere'
If I change the above setting in the external config file the server needs to be restarted for it to take effect.
I googled "grails external reload" and the first result was http://grails.org/plugin/external-config-reload
I'm using Jasper with the Struts2 plugin to generate PDF reports for my web application, as described in this tutorial.
The application uses Weblogic as app server and Apache as webserver in development environment, IIS in testing and production environments.
Locally I put the .jasper files under WEB-INF of the WAR section, which is then put in a EAR after compilation.
PDF generation works locally, passing a relative path (namely WEB-INF/jasper/template.jasper) to the result parameters of the "jasper" result in struts.xml . This does not work when the application is deployed as an EAR.
How can I get my application to find the .jasper template even when deployed as an EAR? I tried to pass in an absolute path pointing to a directory in the same server the EAR is in, but it doesn't work.
And by the way, is there a comprehensive guide to the Struts2 plugin for Jasper? I couldn't find anything except for that tutorial.
In weblogic domain home's webapplications tab; enable the option called Archived Real Path Enabled
works for me in weblogic 11g or later versions