OK - that is what I thought. I have the innards of that working now and have a decent solution for Tomcat. But I need to do more work on it as the way the various app containers handle ears makes that a bit of a pain and for that I expect JNDI may be the only good solution. I also don't use EJBs at all so I don't have support for that yet, although my understanding is that EJB 3 provides some features that could help in this.
FWIW, I've also considered the "unsolvable" problem of static loggers that come from classes in parent classloaders. I actually have something that will work quite nicely in Tomcat but almost certainly won't work in JBoss or other app servers, again due to the various ways those containers deal with class loaders for enterprise applications. I took a look at JULI last night and Tomcat is doing some interesting things in there but I think what they are doing may only work in Tomcat. Ralph On Jun 29, 2011, at 3:40 PM, Mark Struberg wrote: > [X] to have their own configuration > > In fact this is only needed for 'shared' libraries like OpenWebBeans, > MyFaces, OpenJPA, OpenEJB and stuff. Basically all things which comes as part > of a container. But in that case it would be really nice ;) > > Ideally one could provide a configuration of packages which are 'shared'. > > LieGrue, > strub > > --- On Tue, 6/21/11, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> From: Ralph Goers <ralph.go...@dslextreme.com> >> Subject: Re: log4j-2.0 questions >> To: "Log4J Developers List" <log4j-dev@logging.apache.org> >> Date: Tuesday, June 21, 2011, 7:15 AM >> >> On Jun 20, 2011, at 10:52 PM, Mark Struberg wrote: >> >>> Hi Ralph! >>> >>> The problem is that this should be one of n >> 'pluggable' logger implementations. Because getting the >> current ContextClassLoader (for some servers you even need >> to do this via a doPrivileged block) can be expensive. >> >> Are you saying you want each webapp in a servlet container >> to use the same logging API but have different backing >> implementations or that they should each use the same >> implementation but be able to have their own configuration >> or something else? >> >> The Log4J 2 API locates its implementation(s) by finding >> all the instances of META-INF/log4j-provider.xml. At >> the moment it expects to find just one. I haven't really >> figured out what it should do if there is more than one >> implementation. But I'm still not sure if that is what >> you are talking about (hence my question above). I >> guess what I'm asking is if what Logback is doing is >> sufficient or if you think there is something else that >> needs to be done as I don't believe SLF4J or Logback do >> anything in doPrivileged blocks and I don't believe Log4j >> 1.x does either. From the way I understand that >> Logback handles this is that it looks for the implementation >> on the current Threads ContextClassLoader and if that fails >> then it uses the ClassLoader of the class doing the loading. >> I've pretty much planned on doing the same thing. >> >> Ralph >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
