ConfigLocationUri jndi vs file
Hi, Using log4j2 v2.3 (and also tested with v2.9.1), when deploying a war with the following config in servlet 3.0 web.xml file: log4j2 configuration file log4jConfiguration WEB-INF/classes/log4j2.xml when tried to monitor the logger via JMX, noticed that the ConfigLocationUri=jndi:/localhost/myapp/WEB-INF/classes/log4j2.xml instead of ConfigLocationUri=file:///home/tomcat/webapps/myapp/WEB-INF/classes/log4j2.xml The current issue we're seeing now is that the runtime modifying of the log4j2.xml logger level didn't seem to work even with setting in log4j2.xml With log4j2 v2.3 jmx, also noticed that the jndi is using DefaultConfigMonitor class vs the file:/// one is using FileConfigMonitor class So my question is: - does the config monitorInterval only works if it's using file:// in ConfigLocationUri? - if yes, how to config to use file:/// instead of jndi: in the ConfigLocationUri? thanks! Bill - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: ConfigLocationUri jndi vs file
On 2017-09-26 12:11, "billok...@gmail.com" wrote: > Hi, > > Using log4j2 v2.3 (and also tested with v2.9.1), when deploying a war with > the following config in servlet 3.0 web.xml file: > > > log4j2 configuration file > log4jConfiguration > WEB-INF/classes/log4j2.xml > > > > when tried to monitor the logger via JMX, noticed that the > ConfigLocationUri=jndi:/localhost/myapp/WEB-INF/classes/log4j2.xml > instead of > ConfigLocationUri=file:///home/tomcat/webapps/myapp/WEB-INF/classes/log4j2.xml > > The current issue we're seeing now is that the runtime modifying of the > log4j2.xml logger level didn't seem to work even with setting in log4j2.xml > > > With log4j2 v2.3 jmx, also noticed that the jndi is using > DefaultConfigMonitor class vs the file:/// one is using FileConfigMonitor > class > > So my question is: > - does the config monitorInterval only works if it's using file:// in > ConfigLocationUri? > - if yes, how to config to use file:/// instead of jndi: in the > ConfigLocationUri? > > thanks! > Bill > > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > I think I figured out the issue, seems related to the log4jConfiguration > setting... - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: ConfigLocationUri jndi vs file
I think I figured out the issue, seems related to the log4jConfiguration setting... (sorry messed up the reply last time) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
issues with log4j-web.jar deployed location
Hi,
should log4j-web.jar be packaged in individual web app WEB-INF/lib or can it be
deployed in tomcat/lib (to be shared by several web apps)?
Tested with log4j2 v2.6 and latest v2.9.1, and noticed that it seems to work
either way when a webapp is first deployed. BUT if having a log4j2.xml
configured like:
when the webapp, say, MyApp is loaded, it will correctly use the
web:contextPath lookup and create a MyApp.log file. But after modifying the
log4j2.xml log level, the configuration will get reloaded as expected, BUT then
instead of logging to the original MyApp.log file, it will create a
${web:contextPath}.log
file and logging to that new file.
That problem only happens if the log4j2-web.jar file is put in tomcat/lib,
instead of packaged in MyApp/WEB-INF/lib
So just want to confirm if log4j-web.jar should always be packaged in
WEB-INF/lib?
thanks!
Bill
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: issues with log4j-web.jar deployed location
thanks a lot for the prompt reply and explanation!
the reason for using the log4j-web is to have each webapp logs to it's own log
file, thus the ${web:contextPath}.log. But packaging the log4j-web in the
webapp/lib would make sense.
-Bill
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Issue with log4jConfiguration setting
Hi, With log4j2 v 2.9.1 (same issue in previous version 2.6), by putting the log4j2.xml file in WEB-INF/classes, log4j will eventually locate that config file as 'file:/' ConfigLocationUri: file:/opt/tomcat/webapps/log4jTest/WEB-INF/classes/log4j2.xml and the config file monitoring WILL WORK properly. But when try to specify the config file by adding this to web.xml: Log4j Test log4j2 configuration file log4jConfiguration /WEB-INF/classes/log4j2.xml it will be retrieved as (view in jmx): ConfigLocationUri: jndi:/localhost/log4jTest/WEB-INF/classes/log4j2.xml The problem with 'jndi:/' is that the config file seems NO LONGER being watched, and thus the file monitor/reload DID NOT work. Question: - is this a bug or how to make the file set via log4jConfiguration (using path relative to web context, like the /WEB-INF/...) being monitored? In addition to that, in the jndi:/ case, in jmx, the following Exception shown in the ConfigText field java.lang.IllegalStateException: Illegal class loader binding at org.apache.naming.resources.DirContextURLStreamHandler.get(DirContextURLStreamHandler.java:228) at org.apache.naming.resources.DirContextURLStreamHandler.openConnection(DirContextURLStreamHandler.java:90) at java.net.URL.openConnection(URL.java:979)at java.net.URL.openStream(URL.java:1045) at org.apache.logging.log4j.core.config.ConfigurationSource.resetInputStream(ConfigurationSource.java:202) at org.apache.logging.log4j.core.jmx.LoggerContextAdmin.getConfigText(LoggerContextAdmin.java:158) at org.apache.logging.log4j.core.jmx.LoggerContextAdmin.getConfigText(LoggerContextAdmin.java:151) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83) at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206) at com.sun.jmx.mbeanserver.MBeanSupport.getAttributes(MBeanSupport.java:213) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBeanServerInterceptor.java:709) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttributes(JmxMBeanServer.java:705) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1449) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401) at javax.management.remote.rmi.RMIConnectionImpl.getAttributes(RMIConnectionImpl.java:675) at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) at sun.rmi.transport.Transport$1.run(Transport.java:200) at sun.rmi.transport.Transport$1.run(Transport.java:197) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:196) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Thanks! Bill - To unsubscribe, e-mail: log4j-user
loggerContext for container shared lib
Hi, we have multiple webapps, say, webapp1 and webapp2, that use a shared apache lib (say commonLib, which also uses log4j logging) that deployed as jndi resource in tomcat (thus was put in tomcat/lib), and followings are our log4j jars deploy location: tomcat/lib: - log4j-core.jar, log4j-api.jar - commonLib.jar webapp1 and webapp2, in /WEB-INF: - classes/log4j2.xml - lib/log4j2-web.jar When loading, the ClassLoaderContextSelector correctly uses the webappClassloader to load the log4j config for webapp1 and webapp2. But for the commonLib loggerContext, depending on which webapp got loaded first, the commonLib loggerContext will either be using webapp1/WEB-INF/classes/log4j2.xml or webapp2/WEB-INF/classes/log4j2.xml This poses the problem that if say the commonLib loggerContext is using webapp1/WEB-INF/classes/log4j2.xml then webapp1 got undeployed, then the commonLib loggerContext will be referencing a no longer existed config file. any advise on how to handle or resolve the config issue for shared lib loggerContext that uses log4j? Thanks! Bill - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: loggerContext for container shared lib
Note: in the above example, 3 loggerContext will be created, as: - webapp1 - webapp2 - 6dde5c8d (for the commonLib that uses webapp1 log4j2.xml) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: loggerContext for container shared lib
Thanks for looking into this! I do have a log4j2.xml in tomcat/lib, was thinking that would be used by the common classloader for the commomLib log... I guess the problem is that the commonLib classes were only referenced by the webapp code, thus the loggerContext for the commonLib was created during the webapp loading. Followings are the debug logs for reference: --- DEBUG StatusLogger Log4jServletContainerInitializer starting up Log4j in Servlet 3.0+ environment. DEBUG StatusLogger Using ShutdownCallbackRegistry class org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry DEBUG StatusLogger Using the servlet context name "webapp1". DEBUG StatusLogger getConfigURI found [classpath:log4j2.xml] in servletContext at [classpath:log4j2.xml] DEBUG StatusLogger Took 0.119686 seconds to load 204 plugins from WebappClassLoader context: /webapp1 delegate: false repositories: /WEB-INF/classes/ --> Parent Classloader: java.net.URLClassLoader@6dde5c8c .. DEBUG StatusLogger Starting LoggerContext[name=webapp1] from configuration at classpath:log4j2.xml .. // then after initialized some of the code that referenced the commonLib classes DEBUG StatusLogger Starting LoggerContext[name=6dde5c8c, org.apache.logging.log4j.core.LoggerContext@3240b374]... DEBUG StatusLogger Reconfiguration started for context[name=6dde5c8c] at URI null (org.apache.logging.log4j.core.LoggerContext@3240b374) with optional ClassLoader: null DEBUG StatusLogger Using configurationFactory org.apache.logging.log4j.core.config.ConfigurationFactory$Factory@5b34ed62 TRACE StatusLogger Trying to find [log4j2-test6dde5c8c.properties] using context class loader WebappClassLoader context: /webapp1 delegate: false repositories: /WEB-INF/classes/ --> Parent Classloader: java.net.URLClassLoader@6dde5c8c .. TRACE StatusLogger Trying to find [log4j2.jsn] using ClassLoader.getSystemResource(). TRACE StatusLogger Trying to find [log4j2.xml] using context class loader WebappClassLoader context: /webapp1 delegate: false repositories: /WEB-INF/classes/ --> Parent Classloader: java.net.URLClassLoader@6dde5c8c - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: loggerContext for container shared lib
Jira ticket created: LOG4J2-2065 Thanks! Bill On 2017-10-05 06:39, Apache wrote: > As I suspected your log shows it using the wrong ClassLoader to locate the > configuration. Please create a Jira issue with this information. > > Ralph > > > On Oct 5, 2017, at 1:31 AM, "billok...@gmail.com" > > wrote: > > > > Thanks for looking into this! > > > > I do have a log4j2.xml in tomcat/lib, was thinking that would be used by > > the common classloader for the commomLib log... > > > > I guess the problem is that the commonLib classes were only referenced by > > the webapp code, thus the loggerContext for the commonLib was created > > during the webapp loading. Followings are the debug logs for reference: > > > > --- > > DEBUG StatusLogger Log4jServletContainerInitializer starting up Log4j in > > Servlet 3.0+ environment. > > DEBUG StatusLogger Using ShutdownCallbackRegistry class > > org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry > > DEBUG StatusLogger Using the servlet context name "webapp1". > > DEBUG StatusLogger getConfigURI found [classpath:log4j2.xml] in > > servletContext at [classpath:log4j2.xml] > > DEBUG StatusLogger Took 0.119686 seconds to load 204 plugins from > > WebappClassLoader > > context: /webapp1 > > delegate: false > > repositories: > >/WEB-INF/classes/ > > --> Parent Classloader: > > java.net.URLClassLoader@6dde5c8c > > .. > > DEBUG StatusLogger Starting LoggerContext[name=webapp1] from configuration > > at classpath:log4j2.xml > > .. > > // then after initialized some of the code that referenced the commonLib > > classes > > > > DEBUG StatusLogger Starting LoggerContext[name=6dde5c8c, > > org.apache.logging.log4j.core.LoggerContext@3240b374]... > > DEBUG StatusLogger Reconfiguration started for context[name=6dde5c8c] at > > URI null (org.apache.logging.log4j.core.LoggerContext@3240b374) with > > optional ClassLoader: null > > DEBUG StatusLogger Using configurationFactory > > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory@5b34ed62 > > TRACE StatusLogger Trying to find [log4j2-test6dde5c8c.properties] using > > context class loader WebappClassLoader > > context: /webapp1 > > delegate: false > > repositories: > >/WEB-INF/classes/ > > --> Parent Classloader: > > java.net.URLClassLoader@6dde5c8c > > .. > > TRACE StatusLogger Trying to find [log4j2.jsn] using > > ClassLoader.getSystemResource(). > > TRACE StatusLogger Trying to find [log4j2.xml] using context class loader > > WebappClassLoader > > context: /webapp1 > > delegate: false > > repositories: > >/WEB-INF/classes/ > > --> Parent Classloader: > > java.net.URLClassLoader@6dde5c8c > > > > - > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > > > > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
