anomalies running log4j v 2.2 on Tomcat
I would be grateful for any input the members of this list can provide about the following situation. We are running Tomcat 8.0.39, deploying on it a number of web applications using log4j2, the jars for which are packaged into the war files. These webapps are built in various environments. One build environment (our "old" environment) cannot build with any JDK > 1.6. Therefore it uses Log4j2 v.2.2 and embeds these jars into the war files it produces. Tomcat itself is running JDK 1.8. In catalina.out, we see the following error messages on startup whenever a webapp built in the "old" environment is loaded. There are two anomalies: 1) the logger context names are numeric. On those built with JDK1.8 and log4j 2.5+ they are derived from the name of the Webapp. 2) the ClassCastException errors. In spite of the errors, the affected applications do seem to produce the logs that they have been configured to produce. Are these errors a product of using such an old version of log4j2? Would we expect them to disappear with a more modern version? Do they indicate a serious problem? Yes, I know we should be using a more modern JDK and Log4j, but inertia is a powerful force. :-( Thanks in advance for any information anyone is able to provide. 2017-04-17 20:24:34,035 DEBUG Starting LoggerContext[name=1728191654] from configuration at file:///usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml 2017-04-17 20:24:34,036 DEBUG Starting LoggerContext[name=1728191654, org.apache.logging.log4j.core.LoggerContext@207a11b8] with configuration XmlConfiguration[location=/usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml]... 2017-04-17 20:24:34,038 DEBUG Shutdown hook enabled. Registering a new one. 2017-04-17 20:24:34,040 DEBUG Starting configuration XmlConfiguration[location=/usr/local/vtone/plat/ocsWeb/config/ocslog70Web.xml] 2017-04-17 20:24:34,041 DEBUG PluginManager 'Core' found 98 plugins 2017-04-17 20:24:34,041 DEBUG PluginManager 'Level' found 0 plugins 2017-04-17 20:24:34,047 DEBUG PluginManager 'Lookup' found 14 plugins 2017-04-17 20:24:34,048 ERROR Unable to create Lookup for marker java.lang.ClassCastException: class org.apache.logging.log4j.core.lookup.MarkerLookup at java.lang.Class.asSubclass(Class.java:3404) at org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:64) at org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:346) at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359) at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:169) at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:204) at org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:109) at org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:157) at org.apache.logging.log4j.web.Log4jWebInitializerImpl.start(Log4jWebInitializerImpl.java:107) at org.apache.logging.log4j.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:57) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5303) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:753) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:729) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:940) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1816) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2017-04-17 20:24:34,051 ERROR Unable to create Lookup for main java.lang.ClassCastException: class org.apache.logging.log4j.core.lookup.MainMapLookup at java.lang.Class.asSubclass(Class.java:3404) at org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:64) at org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:346) at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:359) at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.jav
Programmatically determine if logger is "OFF"
"OFF" is a level usable in a logging configuration file. I have a need to see if a logger is configured this way. There is no API in logger that checks this. There is a workaround of course - if isFatalEnabled() returns false, then the logger is OFF. But it would be trivial to add an isOff() method and a good thing to have it. - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: jboss-logging vs log4j2 in ejb-client application
OK, so missing or conflicting logging between my client code and JBoss's client library is not the CAUSE of the NoClassDefFoundError. Still, maybe it would be useful to see the logging emitted by the JBoss EJB Client library code, in an attempt to find the cause. The JBoss EJB Client library code has import org.jboss.logging.Logger; This is an abstract class. I previously said that JBoss does not support log4j2 but this may not be entirely true. I notice in looking at the JBoss source code, a class called org.jboss.logging.Log4j2Logger, which extends org.jboss.logging.Logger. Now how do I make use of this? This Hibernate document provided what I needed to know: http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html Since version 4.0, Hibernate has used the JBoss Logging library for its logging needs. Like SLF4J and Jakarta’s commons-logging, JBoss Logging is a "logging bridge" providing integration with numerous logging frameworks. JBoss Logging was chosen because of its i18n support and its support for "message ids". This is largely the seminal documentation of JBoss Logging since JBoss Logging currently provides no documentation of its own. Supported Back-ends JBoss Logging understands the following back-ends as first-class citizens: JBoss LogManager (mainly used only inside the WildFly app server) Log4j 2 Log4j 1 Slf4j JDK logging And voila, the logging output by JBoss showed me what I needed to see to solve my problem. Very useful, and not in the general JBoss documentation, as far as I could see. -Original Message- From: Apache [mailto:ralph.go...@dslextreme.com] Sent: Monday, January 16, 2017 2:16 PM To: Log4J Users List Subject: Re: jboss-logging vs log4j2 in ejb-client application That can be tough to solve because frequently you will get a NoClassDefFoundError on Class A even though it is there because it has a reference to Class B or something in Class B and it isn’t there. Unfortunately, the JVM isn’t very good about letting you know what is actually missing. Ralph > On Jan 16, 2017, at 12:25 PM, COHEN, STEVEN M wrote: > > Thanks, Ralph, for busting my theory of the case. :-) > > I built a test application, from one of the examples floating around on the > Internet, added log4j2 to it, built the client and ran it on my server. It > worked without incident, disproving my theory. > > Ugh, now to figure out how to debug java.lang.NoClassDefFoundError. > > > > -Original Message- > From: Apache [mailto:ralph.go...@dslextreme.com] > Sent: Monday, January 16, 2017 10:43 AM > To: Log4J Users List > Subject: Re: jboss-logging vs log4j2 in ejb-client application > > Can you provide a test application along with a link to the JBoss version you > are using? I haven’t worked with JBoss in several years but would happy to > take a look - if for no other reason than to do something with LOG4J2-18. > > Ralph > >> On Jan 16, 2017, at 9:11 AM, COHEN, STEVEN M wrote: >> >> Our team is fairly standardized on using log4j2 over log4j, commons-logging >> or any other framework. >> >> This had presented some issues with jboss-eap which does not support log4j2. >> Nevertheless, for applications running on the jboss-server it was fairly >> easy, and even a good thing to package log4j2 as a jboss module and do all >> our application logging through that. Let JBoss use jboss-logging for its >> internal use. >> >> I believe this pattern has now broken down over a standalone client >> application that talks to the EJBs we deploy on another server. Although I >> can easily put log4j2 on the runtime classpath of this application, the >> client libraries that one must also include in order to talk to JBoss, need >> jboss-logging. So I have both sets of jars on my classpath. I believe that >> this has resulted in >> >> java.lang.NoClassDefFoundError: Could not initialize class >> org.jboss.ejb.client.EJBClientContext >> >> errors at runtime. >> >> I am not sure that the logging conflict is the reason, but at this point I >> am "liking" this theory as my #1 suspect. I have looked at all the >> dependency graphs and find that nothing is missing, so what else could it be? >> >> I could switch to log4j1 for the client app, but some of our code must run >> on jboss so that isn't a good solution. >> >> Is there a standard way to handle this that I could try to prevent any >> conflicts? >> >> >> - >> To unsubscribe, e-mail: log4j-user-
RE: jboss-logging vs log4j2 in ejb-client application
Thanks, Ralph, for busting my theory of the case. :-) I built a test application, from one of the examples floating around on the Internet, added log4j2 to it, built the client and ran it on my server. It worked without incident, disproving my theory. Ugh, now to figure out how to debug java.lang.NoClassDefFoundError. -Original Message- From: Apache [mailto:ralph.go...@dslextreme.com] Sent: Monday, January 16, 2017 10:43 AM To: Log4J Users List Subject: Re: jboss-logging vs log4j2 in ejb-client application Can you provide a test application along with a link to the JBoss version you are using? I haven’t worked with JBoss in several years but would happy to take a look - if for no other reason than to do something with LOG4J2-18. Ralph > On Jan 16, 2017, at 9:11 AM, COHEN, STEVEN M wrote: > > Our team is fairly standardized on using log4j2 over log4j, commons-logging > or any other framework. > > This had presented some issues with jboss-eap which does not support log4j2. > Nevertheless, for applications running on the jboss-server it was fairly > easy, and even a good thing to package log4j2 as a jboss module and do all > our application logging through that. Let JBoss use jboss-logging for its > internal use. > > I believe this pattern has now broken down over a standalone client > application that talks to the EJBs we deploy on another server. Although I > can easily put log4j2 on the runtime classpath of this application, the > client libraries that one must also include in order to talk to JBoss, need > jboss-logging. So I have both sets of jars on my classpath. I believe that > this has resulted in > > java.lang.NoClassDefFoundError: Could not initialize class > org.jboss.ejb.client.EJBClientContext > > errors at runtime. > > I am not sure that the logging conflict is the reason, but at this point I am > "liking" this theory as my #1 suspect. I have looked at all the dependency > graphs and find that nothing is missing, so what else could it be? > > I could switch to log4j1 for the client app, but some of our code must run on > jboss so that isn't a good solution. > > Is there a standard way to handle this that I could try to prevent any > conflicts? > > > - > 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
jboss-logging vs log4j2 in ejb-client application
Our team is fairly standardized on using log4j2 over log4j, commons-logging or any other framework. This had presented some issues with jboss-eap which does not support log4j2. Nevertheless, for applications running on the jboss-server it was fairly easy, and even a good thing to package log4j2 as a jboss module and do all our application logging through that. Let JBoss use jboss-logging for its internal use. I believe this pattern has now broken down over a standalone client application that talks to the EJBs we deploy on another server. Although I can easily put log4j2 on the runtime classpath of this application, the client libraries that one must also include in order to talk to JBoss, need jboss-logging. So I have both sets of jars on my classpath. I believe that this has resulted in java.lang.NoClassDefFoundError: Could not initialize class org.jboss.ejb.client.EJBClientContext errors at runtime. I am not sure that the logging conflict is the reason, but at this point I am "liking" this theory as my #1 suspect. I have looked at all the dependency graphs and find that nothing is missing, so what else could it be? I could switch to log4j1 for the client app, but some of our code must run on jboss so that isn't a good solution. Is there a standard way to handle this that I could try to prevent any conflicts? - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: Copying appenders and loggers from a confgiruation to a builder
https://issues.apache.org/jira/browse/LOG4J2-1713 Thanks Gary -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Thursday, November 17, 2016 12:49 PM To: Log4J Users List Subject: Re: Copying appenders and loggers from a confgiruation to a builder You need to click the red text in the "Create" button, not the drop down arrow. From a high level you want to do something like this: c1 = load config from XML file 1 (but do not apply the c1 configuration) c2 = load config from XML file 2 (but do not apply the c2 configuration) c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk right? sounds reasonable. Dare I mention... XSL? [Ducks under flying tomatoes.] Gary On Thu, Nov 17, 2016 at 9:41 AM, COHEN, STEVEN M wrote: > I don't think I'm able to do so. Although I set up an account on the > JIRA and have logged in, the only thing I'm allowed to "Create" is a > "Service Desk Request". There is nothing there about reporting a bug, > requesting a feature, etc. > > CompositeConfiguration does not help either. My use case doesn't seem > to be supported. I don't want to programmatically create a > configuration. I want to combine configurations and output the combined > config to disk. > Then that can be passed in as the new configuration. > > The only thing that can generate XML is a ConfigurationBuilder. But > there is no way to transfer loaded Configurtations to a Builder nor as > there a way to generate XML from a built configuration. > > -Original Message- > From: Gary Gregory [mailto:garydgreg...@gmail.com] > Sent: Thursday, November 17, 2016 9:52 AM > To: Log4J Users List > Subject: Re: Copying appenders and loggers from a confgiruation to a > builder > > Please feel free to record your feature request in JIRA: > https://issues.apache.org/jira/browse/LOG4J2 > > Gary > > On Thu, Nov 17, 2016 at 7:47 AM, COHEN, STEVEN M wrote: > > > Thanks, that almost works for me, and will have to do, I suppose. > > The problem is that I was hoping to be able to load each subconfig > > in first, filtering in any property definitions, which would then > > lead to writable output that would not contain properties, but their > > expanded values. It would seem that with this approach, it would > > almost be better to not use properties at all in the subconfigs. > > > > I guess this would have to be a feature request, but in the meantime > > I might give CompositeConfiguration a try. > > > > -Original Message- > > From: Matt Sicker [mailto:boa...@gmail.com] > > Sent: Thursday, November 17, 2016 9:34 AM > > To: Log4J Users List > > Subject: Re: Copying appenders and loggers from a confgiruation to a > > builder > > > > I don't believe there is an API in ConfigurationBuilder that uses > > actual plugin objects. That would certainly be a new feature. > > However, you did mention combining configuration files which is > > already implemented through composite configuration: > > http://logging.apache.org/log4j/2.x/manual/configuration.html# > > CompositeConfiguration > > > > On 17 November 2016 at 09:29, COHEN, STEVEN M wrote: > > > > > I am trying to construct a program that basically reads a bunch of > > > log4j2 configuration files and combines them into one, writing > > > this back to disk using the new > > > ConfigurationBuilder.writeXmlConfiguration(OutputStream) > > > method. > > > > > > But I run up against what seems to me to be a gap in the API > > > unless I am missing something: > > > Having created a ConfigurationBuilder for the destination file and > > > having read one of the to-be-combined configuration files into a > > > Configuration object, there appears to be nothing in the > > > ConfigurationBuilder interface that would allow, say, one of the > > > appenders from the read-in configuration to be copied, as a whole > > > object,into the builder, short of deconstructing it down to its > > constituent elements and adding them one by one. > > > > > > Is there a way to copy an appender from one configuration to > > > another without drilling down into all its constituent parts? And > > > similarly, a way to copy a logger from one configuration to > > > another without drilling down to its constituent parts? Or must I > > > write all this code > > myself? > > > > > > > > > > > > -- > > > -- > > &
RE: Copying appenders and loggers from a confgiruation to a builder
Duh! How did I miss that? -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Thursday, November 17, 2016 12:49 PM To: Log4J Users List Subject: Re: Copying appenders and loggers from a confgiruation to a builder You need to click the red text in the "Create" button, not the drop down arrow. From a high level you want to do something like this: c1 = load config from XML file 1 (but do not apply the c1 configuration) c2 = load config from XML file 2 (but do not apply the c2 configuration) c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk right? sounds reasonable. Dare I mention... XSL? [Ducks under flying tomatoes.] Gary On Thu, Nov 17, 2016 at 9:41 AM, COHEN, STEVEN M wrote: > I don't think I'm able to do so. Although I set up an account on the > JIRA and have logged in, the only thing I'm allowed to "Create" is a > "Service Desk Request". There is nothing there about reporting a bug, > requesting a feature, etc. > > CompositeConfiguration does not help either. My use case doesn't seem > to be supported. I don't want to programmatically create a > configuration. I want to combine configurations and output the combined > config to disk. > Then that can be passed in as the new configuration. > > The only thing that can generate XML is a ConfigurationBuilder. But > there is no way to transfer loaded Configurtations to a Builder nor as > there a way to generate XML from a built configuration. > > -Original Message- > From: Gary Gregory [mailto:garydgreg...@gmail.com] > Sent: Thursday, November 17, 2016 9:52 AM > To: Log4J Users List > Subject: Re: Copying appenders and loggers from a confgiruation to a > builder > > Please feel free to record your feature request in JIRA: > https://issues.apache.org/jira/browse/LOG4J2 > > Gary > > On Thu, Nov 17, 2016 at 7:47 AM, COHEN, STEVEN M wrote: > > > Thanks, that almost works for me, and will have to do, I suppose. > > The problem is that I was hoping to be able to load each subconfig > > in first, filtering in any property definitions, which would then > > lead to writable output that would not contain properties, but their > > expanded values. It would seem that with this approach, it would > > almost be better to not use properties at all in the subconfigs. > > > > I guess this would have to be a feature request, but in the meantime > > I might give CompositeConfiguration a try. > > > > -Original Message- > > From: Matt Sicker [mailto:boa...@gmail.com] > > Sent: Thursday, November 17, 2016 9:34 AM > > To: Log4J Users List > > Subject: Re: Copying appenders and loggers from a confgiruation to a > > builder > > > > I don't believe there is an API in ConfigurationBuilder that uses > > actual plugin objects. That would certainly be a new feature. > > However, you did mention combining configuration files which is > > already implemented through composite configuration: > > http://logging.apache.org/log4j/2.x/manual/configuration.html# > > CompositeConfiguration > > > > On 17 November 2016 at 09:29, COHEN, STEVEN M wrote: > > > > > I am trying to construct a program that basically reads a bunch of > > > log4j2 configuration files and combines them into one, writing > > > this back to disk using the new > > > ConfigurationBuilder.writeXmlConfiguration(OutputStream) > > > method. > > > > > > But I run up against what seems to me to be a gap in the API > > > unless I am missing something: > > > Having created a ConfigurationBuilder for the destination file and > > > having read one of the to-be-combined configuration files into a > > > Configuration object, there appears to be nothing in the > > > ConfigurationBuilder interface that would allow, say, one of the > > > appenders from the read-in configuration to be copied, as a whole > > > object,into the builder, short of deconstructing it down to its > > constituent elements and adding them one by one. > > > > > > Is there a way to copy an appender from one configuration to > > > another without drilling down into all its constituent parts? And > > > similarly, a way to copy a logger from one configuration to > > > another without drilling down to its constituent parts? Or must I > > > write all this code > > myself? > > > > > > > > > > > > -- > > > -- > > > - To unsubscribe, e-mail: > > >
RE: Copying appenders and loggers from a confgiruation to a builder
I don't think I'm able to do so. Although I set up an account on the JIRA and have logged in, the only thing I'm allowed to "Create" is a "Service Desk Request". There is nothing there about reporting a bug, requesting a feature, etc. CompositeConfiguration does not help either. My use case doesn't seem to be supported. I don't want to programmatically create a configuration. I want to combine configurations and output the combined config to disk. Then that can be passed in as the new configuration. The only thing that can generate XML is a ConfigurationBuilder. But there is no way to transfer loaded Configurtations to a Builder nor as there a way to generate XML from a built configuration. -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Thursday, November 17, 2016 9:52 AM To: Log4J Users List Subject: Re: Copying appenders and loggers from a confgiruation to a builder Please feel free to record your feature request in JIRA: https://issues.apache.org/jira/browse/LOG4J2 Gary On Thu, Nov 17, 2016 at 7:47 AM, COHEN, STEVEN M wrote: > Thanks, that almost works for me, and will have to do, I suppose. The > problem is that I was hoping to be able to load each subconfig in > first, filtering in any property definitions, which would then lead to > writable output that would not contain properties, but their expanded > values. It would seem that with this approach, it would almost be > better to not use properties at all in the subconfigs. > > I guess this would have to be a feature request, but in the meantime I > might give CompositeConfiguration a try. > > -Original Message- > From: Matt Sicker [mailto:boa...@gmail.com] > Sent: Thursday, November 17, 2016 9:34 AM > To: Log4J Users List > Subject: Re: Copying appenders and loggers from a confgiruation to a > builder > > I don't believe there is an API in ConfigurationBuilder that uses > actual plugin objects. That would certainly be a new feature. However, > you did mention combining configuration files which is already > implemented through composite configuration: > http://logging.apache.org/log4j/2.x/manual/configuration.html# > CompositeConfiguration > > On 17 November 2016 at 09:29, COHEN, STEVEN M wrote: > > > I am trying to construct a program that basically reads a bunch of > > log4j2 configuration files and combines them into one, writing this > > back to disk using the new > > ConfigurationBuilder.writeXmlConfiguration(OutputStream) > > method. > > > > But I run up against what seems to me to be a gap in the API unless > > I am missing something: > > Having created a ConfigurationBuilder for the destination file and > > having read one of the to-be-combined configuration files into a > > Configuration object, there appears to be nothing in the > > ConfigurationBuilder interface that would allow, say, one of the > > appenders from the read-in configuration to be copied, as a whole > > object,into the builder, short of deconstructing it down to its > constituent elements and adding them one by one. > > > > Is there a way to copy an appender from one configuration to another > > without drilling down into all its constituent parts? And > > similarly, a way to copy a logger from one configuration to another > > without drilling down to its constituent parts? Or must I write all > > this code > myself? > > > > > > > > > > - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > > > > -- > Matt Sicker > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
RE: Copying appenders and loggers from a confgiruation to a builder
Looking at the MergeStrategy source code, it seems a bit confusing. The method mergeRootProperties() seems to apply not to elements but to root element attributes such as "monitorInterval", "status", etc. The method might be better named mergeRootAttributes. I think, I will have to adhere to the following rules in order to use CompositeConfiguration: 1. No definitions. Or possibly require system-wide unique names. 2. Only the master config defines root attributes. -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Thursday, November 17, 2016 9:52 AM To: Log4J Users List Subject: Re: Copying appenders and loggers from a confgiruation to a builder Please feel free to record your feature request in JIRA: https://issues.apache.org/jira/browse/LOG4J2 Gary On Thu, Nov 17, 2016 at 7:47 AM, COHEN, STEVEN M wrote: > Thanks, that almost works for me, and will have to do, I suppose. The > problem is that I was hoping to be able to load each subconfig in > first, filtering in any property definitions, which would then lead to > writable output that would not contain properties, but their expanded > values. It would seem that with this approach, it would almost be > better to not use properties at all in the subconfigs. > > I guess this would have to be a feature request, but in the meantime I > might give CompositeConfiguration a try. > > -Original Message- > From: Matt Sicker [mailto:boa...@gmail.com] > Sent: Thursday, November 17, 2016 9:34 AM > To: Log4J Users List > Subject: Re: Copying appenders and loggers from a confgiruation to a > builder > > I don't believe there is an API in ConfigurationBuilder that uses > actual plugin objects. That would certainly be a new feature. However, > you did mention combining configuration files which is already > implemented through composite configuration: > http://logging.apache.org/log4j/2.x/manual/configuration.html# > CompositeConfiguration > > On 17 November 2016 at 09:29, COHEN, STEVEN M wrote: > > > I am trying to construct a program that basically reads a bunch of > > log4j2 configuration files and combines them into one, writing this > > back to disk using the new > > ConfigurationBuilder.writeXmlConfiguration(OutputStream) > > method. > > > > But I run up against what seems to me to be a gap in the API unless > > I am missing something: > > Having created a ConfigurationBuilder for the destination file and > > having read one of the to-be-combined configuration files into a > > Configuration object, there appears to be nothing in the > > ConfigurationBuilder interface that would allow, say, one of the > > appenders from the read-in configuration to be copied, as a whole > > object,into the builder, short of deconstructing it down to its > constituent elements and adding them one by one. > > > > Is there a way to copy an appender from one configuration to another > > without drilling down into all its constituent parts? And > > similarly, a way to copy a logger from one configuration to another > > without drilling down to its constituent parts? Or must I write all > > this code > myself? > > > > > > > > > > - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > > > > -- > Matt Sicker > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
RE: Copying appenders and loggers from a confgiruation to a builder
Thanks, that almost works for me, and will have to do, I suppose. The problem is that I was hoping to be able to load each subconfig in first, filtering in any property definitions, which would then lead to writable output that would not contain properties, but their expanded values. It would seem that with this approach, it would almost be better to not use properties at all in the subconfigs. I guess this would have to be a feature request, but in the meantime I might give CompositeConfiguration a try. -Original Message- From: Matt Sicker [mailto:boa...@gmail.com] Sent: Thursday, November 17, 2016 9:34 AM To: Log4J Users List Subject: Re: Copying appenders and loggers from a confgiruation to a builder I don't believe there is an API in ConfigurationBuilder that uses actual plugin objects. That would certainly be a new feature. However, you did mention combining configuration files which is already implemented through composite configuration: http://logging.apache.org/log4j/2.x/manual/configuration.html#CompositeConfiguration On 17 November 2016 at 09:29, COHEN, STEVEN M wrote: > I am trying to construct a program that basically reads a bunch of > log4j2 configuration files and combines them into one, writing this > back to disk using the new > ConfigurationBuilder.writeXmlConfiguration(OutputStream) > method. > > But I run up against what seems to me to be a gap in the API unless I > am missing something: > Having created a ConfigurationBuilder for the destination file and > having read one of the to-be-combined configuration files into a > Configuration object, there appears to be nothing in the > ConfigurationBuilder interface that would allow, say, one of the > appenders from the read-in configuration to be copied, as a whole > object,into the builder, short of deconstructing it down to its constituent > elements and adding them one by one. > > Is there a way to copy an appender from one configuration to another > without drilling down into all its constituent parts? And similarly, > a way to copy a logger from one configuration to another without > drilling down to its constituent parts? Or must I write all this code myself? > > > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > -- Matt Sicker
Copying appenders and loggers from a confgiruation to a builder
I am trying to construct a program that basically reads a bunch of log4j2 configuration files and combines them into one, writing this back to disk using the new ConfigurationBuilder.writeXmlConfiguration(OutputStream) method. But I run up against what seems to me to be a gap in the API unless I am missing something: Having created a ConfigurationBuilder for the destination file and having read one of the to-be-combined configuration files into a Configuration object, there appears to be nothing in the ConfigurationBuilder interface that would allow, say, one of the appenders from the read-in configuration to be copied, as a whole object,into the builder, short of deconstructing it down to its constituent elements and adding them one by one. Is there a way to copy an appender from one configuration to another without drilling down into all its constituent parts? And similarly, a way to copy a logger from one configuration to another without drilling down to its constituent parts? Or must I write all this code myself? - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: Building log4j2 configuration files programmatically
https://issues.apache.org/jira/browse/LOG4J2-1528 -Original Message- From: Matt Sicker [mailto:boa...@gmail.com] Sent: Wednesday, November 16, 2016 2:11 PM To: Log4J Users List Subject: Re: Building log4j2 configuration files programmatically Damn, you beat me. I thought there was an open jira issue about this and I couldn't find it! On 16 November 2016 at 13:59, Gary Gregory wrote: > Please have a look at: > > org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder. > writeXmlConfiguration(OutputStream) > > and > > https://logging.apache.org/log4j/2.x/manual/customconfig.html > > Gary > > On Wed, Nov 16, 2016 at 9:59 AM, COHEN, STEVEN M wrote: > > > We have the following requirements: > > > > There is a servlet that serves as a front end to many disparate EJBs. > The > > servlet reads the request parameters , decides which EJB they tell > > it to invoke, invoke that EJB from a JNDI lookup on the server. > > Currently this is implemented on WebLogic, but we are trying to port > > it to JBoss. And we'd also like it to use log4j2 rather than log4j. > > > > Both WebLogic and JBoss, and all application servers that I know of, > > have the same relationship to log4j: > > > > There is one Configuration per class loader. That seems to be an > > immutable rule. A Web App deployed in a War file has its own class > > loader. An enterprise application deployed in an EAR file has its > > own class loader. An EJB deployed as an EJB JAR seems to use the > > container's class loader. > > > > But here is the rub: > > We would like to have separate deployment of the EJBs. These > > deployments in our organization are wrapped in RPMs , and they > > deploy the JEE archive (WAR, EAR, or EJB JAR) to the server using > > some script contained in the RPM. Once deployed, the rpm > > postinstall script must also deploy the logging configuration file > > somewhere. In order to achieve this separate deployment of EJBs, we have > > basically two choices: > > > > 1) Maintain the logging configuration of the master servlet webapp > > manually, adding appenders and loggers to the configuration file > > that > also > > contains loggers and appenders for all the other EJBs run from this > servlet > > and separately from the deployment of the EJB itself. > > > > 2) Develop some sort of scheme where each EJB "owns" a temporary > > logging configuration file in an intermediate directory. When an > > RPM for one of the separately deployable EJBs is installed, launch a > > program that reads all the logging configuration files in the > > intermediate directory and writes out a new config file for the > > master servlet that includes the configs for all of these EJBs. > > > > In fact we have such a system already, written in-house many years > > ago, based on log4j-1.x. It's rather crude, but it works. > > > > Is there a better way to do this in log4j2? Is there a way to > > launch > some > > sort of Builder that reads in a Configuration file, allows > > modification > of > > the Configuration loaded and then writes the modified Configuration > > back > to > > a disk file. This would then cause the LoggerContext to update itself. > > > > > > > > - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence > with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b > 8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de41 > 8%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: Building log4j2 configuration files programmatically
In my particular use case, I do not actually need or want to modify the running configuration directly. It is much safer and quite sufficient to generate a new configuration file, then drop it into the proper location. The new ConfigurationBuilder.writeXmlConfiguration(OutputStream) method pointed to me by Gary Gregory, is perfect for my use case. -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Wednesday, November 16, 2016 2:21 PM To: Log4J Users List Subject: Re: Building log4j2 configuration files programmatically Loading the configuration and then modifying it is documented on the web site. As I recall, someone is working on being something that will write the configuration to disk, but at the moment I don’t recall where it resides or what state it is in. Ralph > On Nov 16, 2016, at 10:59 AM, COHEN, STEVEN M wrote: > > We have the following requirements: > > There is a servlet that serves as a front end to many disparate EJBs. The > servlet reads the request parameters , decides which EJB they tell it to > invoke, invoke that EJB from a JNDI lookup on the server. Currently this is > implemented on WebLogic, but we are trying to port it to JBoss. And we'd > also like it to use log4j2 rather than log4j. > > Both WebLogic and JBoss, and all application servers that I know of, have the > same relationship to log4j: > > There is one Configuration per class loader. That seems to be an immutable > rule. A Web App deployed in a War file has its own class loader. An > enterprise application deployed in an EAR file has its own class loader. An > EJB deployed as an EJB JAR seems to use the container's class loader. > > But here is the rub: > We would like to have separate deployment of the EJBs. These deployments in > our organization are wrapped in RPMs , and they deploy the JEE archive (WAR, > EAR, or EJB JAR) to the server using some script contained in the RPM. Once > deployed, the rpm postinstall script must also deploy the logging > configuration file somewhere. In order to achieve this separate deployment > of EJBs, we have basically two choices: > > 1) Maintain the logging configuration of the master servlet webapp manually, > adding appenders and loggers to the configuration file that also contains > loggers and appenders for all the other EJBs run from this servlet and > separately from the deployment of the EJB itself. > > 2) Develop some sort of scheme where each EJB "owns" a temporary logging > configuration file in an intermediate directory. When an RPM for one of the > separately deployable EJBs is installed, launch a program that reads all the > logging configuration files in the intermediate directory and writes out a > new config file for the master servlet that includes the configs for all of > these EJBs. > > In fact we have such a system already, written in-house many years ago, based > on log4j-1.x. It's rather crude, but it works. > > Is there a better way to do this in log4j2? Is there a way to launch some > sort of Builder that reads in a Configuration file, allows modification of > the Configuration loaded and then writes the modified Configuration back to a > disk file. This would then cause the LoggerContext to update itself. > > > - > 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
RE: Building log4j2 configuration files programmatically
Thank you very much Gary. I see this is a new 2.7 feature. We were using 2.5. I would not have found it without your reply. Just what I needed. -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Wednesday, November 16, 2016 2:00 PM To: Log4J Users List Subject: Re: Building log4j2 configuration files programmatically Please have a look at: org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder.writeXmlConfiguration(OutputStream) and https://logging.apache.org/log4j/2.x/manual/customconfig.html Gary On Wed, Nov 16, 2016 at 9:59 AM, COHEN, STEVEN M wrote: > We have the following requirements: > > There is a servlet that serves as a front end to many disparate EJBs. > The servlet reads the request parameters , decides which EJB they tell > it to invoke, invoke that EJB from a JNDI lookup on the server. > Currently this is implemented on WebLogic, but we are trying to port > it to JBoss. And we'd also like it to use log4j2 rather than log4j. > > Both WebLogic and JBoss, and all application servers that I know of, > have the same relationship to log4j: > > There is one Configuration per class loader. That seems to be an > immutable rule. A Web App deployed in a War file has its own class > loader. An enterprise application deployed in an EAR file has its own > class loader. An EJB deployed as an EJB JAR seems to use the > container's class loader. > > But here is the rub: > We would like to have separate deployment of the EJBs. These > deployments in our organization are wrapped in RPMs , and they deploy > the JEE archive (WAR, EAR, or EJB JAR) to the server using some script > contained in the RPM. Once deployed, the rpm postinstall script must > also deploy the logging configuration file somewhere. In order to > achieve this separate deployment of EJBs, we have basically two choices: > > 1) Maintain the logging configuration of the master servlet webapp > manually, adding appenders and loggers to the configuration file that > also contains loggers and appenders for all the other EJBs run from > this servlet and separately from the deployment of the EJB itself. > > 2) Develop some sort of scheme where each EJB "owns" a temporary > logging configuration file in an intermediate directory. When an RPM > for one of the separately deployable EJBs is installed, launch a > program that reads all the logging configuration files in the > intermediate directory and writes out a new config file for the master > servlet that includes the configs for all of these EJBs. > > In fact we have such a system already, written in-house many years > ago, based on log4j-1.x. It's rather crude, but it works. > > Is there a better way to do this in log4j2? Is there a way to launch > some sort of Builder that reads in a Configuration file, allows > modification of the Configuration loaded and then writes the modified > Configuration back to a disk file. This would then cause the LoggerContext > to update itself. > > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
RE: Building log4j2 configuration files programmatically
Apparently not. The kind of help I would like to have from log4j2 is some way of writing a configuration to disk. This doesn't seem to exist, at least not for xml configs. -Original Message- From: COHEN, STEVEN M Sent: Wednesday, November 16, 2016 12:00 PM To: log4j-user@logging.apache.org Subject: Building log4j2 configuration files programmatically *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. We have the following requirements: There is a servlet that serves as a front end to many disparate EJBs. The servlet reads the request parameters , decides which EJB they tell it to invoke, invoke that EJB from a JNDI lookup on the server. Currently this is implemented on WebLogic, but we are trying to port it to JBoss. And we'd also like it to use log4j2 rather than log4j. Both WebLogic and JBoss, and all application servers that I know of, have the same relationship to log4j: There is one Configuration per class loader. That seems to be an immutable rule. A Web App deployed in a War file has its own class loader. An enterprise application deployed in an EAR file has its own class loader. An EJB deployed as an EJB JAR seems to use the container's class loader. But here is the rub: We would like to have separate deployment of the EJBs. These deployments in our organization are wrapped in RPMs , and they deploy the JEE archive (WAR, EAR, or EJB JAR) to the server using some script contained in the RPM. Once deployed, the rpm postinstall script must also deploy the logging configuration file somewhere. In order to achieve this separate deployment of EJBs, we have basically two choices: 1) Maintain the logging configuration of the master servlet webapp manually, adding appenders and loggers to the configuration file that also contains loggers and appenders for all the other EJBs run from this servlet and separately from the deployment of the EJB itself. 2) Develop some sort of scheme where each EJB "owns" a temporary logging configuration file in an intermediate directory. When an RPM for one of the separately deployable EJBs is installed, launch a program that reads all the logging configuration files in the intermediate directory and writes out a new config file for the master servlet that includes the configs for all of these EJBs. In fact we have such a system already, written in-house many years ago, based on log4j-1.x. It's rather crude, but it works. Is there a better way to do this in log4j2? Is there a way to launch some sort of Builder that reads in a Configuration file, allows modification of the Configuration loaded and then writes the modified Configuration back to a disk file. This would then cause the LoggerContext to update itself. - 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
Building log4j2 configuration files programmatically
We have the following requirements: There is a servlet that serves as a front end to many disparate EJBs. The servlet reads the request parameters , decides which EJB they tell it to invoke, invoke that EJB from a JNDI lookup on the server. Currently this is implemented on WebLogic, but we are trying to port it to JBoss. And we'd also like it to use log4j2 rather than log4j. Both WebLogic and JBoss, and all application servers that I know of, have the same relationship to log4j: There is one Configuration per class loader. That seems to be an immutable rule. A Web App deployed in a War file has its own class loader. An enterprise application deployed in an EAR file has its own class loader. An EJB deployed as an EJB JAR seems to use the container's class loader. But here is the rub: We would like to have separate deployment of the EJBs. These deployments in our organization are wrapped in RPMs , and they deploy the JEE archive (WAR, EAR, or EJB JAR) to the server using some script contained in the RPM. Once deployed, the rpm postinstall script must also deploy the logging configuration file somewhere. In order to achieve this separate deployment of EJBs, we have basically two choices: 1) Maintain the logging configuration of the master servlet webapp manually, adding appenders and loggers to the configuration file that also contains loggers and appenders for all the other EJBs run from this servlet and separately from the deployment of the EJB itself. 2) Develop some sort of scheme where each EJB "owns" a temporary logging configuration file in an intermediate directory. When an RPM for one of the separately deployable EJBs is installed, launch a program that reads all the logging configuration files in the intermediate directory and writes out a new config file for the master servlet that includes the configs for all of these EJBs. In fact we have such a system already, written in-house many years ago, based on log4j-1.x. It's rather crude, but it works. Is there a better way to do this in log4j2? Is there a way to launch some sort of Builder that reads in a Configuration file, allows modification of the Configuration loaded and then writes the modified Configuration back to a disk file. This would then cause the LoggerContext to update itself. - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Example of using Log4jContextFactory?
The goal: to configure log4j2 logging on a standalone EJB deployed to a JBoss
EAP7 server in an EJB jar. We do not wish to use the loggers supplied by JBoss
for our applications. I find that I can deploy a log4j2.xml file at the root
of the ejb jar and it does get seen by JBoss but logging still isn't happening.
Referring to https://logging.apache.org/log4j/2.0/manual/extending.html, I see
a glimmer of hope that this may provide a solution. The LoggerContextFactory
and ContextSelector sections seem to provide a possibility. My approach is to
create my own logging factory extending
org.apache.logging.log4j.core.impl.Log4jContextFactory. This makes a
Log4jContextFactory that uses the JndiContextSelector and I will add envEntries
to my EJB configuration to define the Jndi context.
public class EjbJarLoggingContextFactory extends Log4jContextFactory {
public EjbJarLoggingContextFactory() {
super(new
org.apache.logging.log4j.core.selector.JndiContextSelector());
}
}
Now how to tell log4j about this? The LoggerContextFactory of the document is
a bit vague, perhaps even contradictory:
The LoggerContextFactory binds the Log4j API to its implementation. The Log4j
LogManager locates a LoggerContextFactory by locating all instances of
META-INF/log4j-provider.properties, a standard java.util.Properties file, and
then inspecting each to verify that it specifies a value for the
Log4jAPIVersion property that conforms to the version required by the
LogManager. If more than one valid implementation is located the value for
FactoryPriority will be used to identify the factory with the highest priority.
Finally, the value of the LoggerContextFactory property will be used to locate
the LoggerContextFactory. In Log4j 2 this is provided by Log4jContextFactory.
Applications may change the LoggerContextFactory that will be used by
1. Implementing a new LoggerContextFactory and creating a
log4j-provider.properties to reference it making sure that it has the highest
priority.
2 . Create a new log4j-provider.xml and configure it with the desired
LoggerContextFactory making sure that it has the highest priority.
3. Setting the system property log4j2.loggerContextFactory to the name of
the LoggerContextFactory class to use.
4. Setting the property "log4j2.loggerContextFactory" in a properties file
named "log4j2.LogManager.properties" to the name of the LoggerContextFactory
class to use. The properties file must be on the classpath.
First we are told that it locates all instances of
META-INF/log4j-provider.properties. But then it goes on to list four possible
ways to change this. I settled on #4, created a log4j2LogManager.properties
file defining the log4j2.loggerContextFactory property to point at my Factory
class.
It doesn't work. No logging occurs. In the jboss logs I see no sign that my
properties file has been consulted, and nothing happens.
So I have these questions:
1. Does the introductory test about META-INF/log4j-provider.properties
contradict the four methods suggested below. If not, what am I not
understanding?
2. Is there a worked example somewhere of setting up such a configuration that
I can consult?
3. Is there a better way to achieve the goal I am trying to achieve - get
logging to work in a standalone EJB?
Thanks.
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
