[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
