Sorry for the delay, follow up further... > By default, the resolver only scans classes in > org.apache.logging.log4j packages and subpackages.
But that still does perform much worse than a simple set of properties files which can get picked up directly via ClassLoader#getResources, isn't? How do you perform this class scan? 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, 6:33 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. > > > > It's really not needed everywhere but only for shared > libraries. But in that case it's really important. > > > > Btw, you said that you use annotations for some parts: > doesn't this take too much power? You would need to scan all > classes at startup, isn't? > > By default, the resolver only scans classes in > org.apache.logging.log4j packages and subpackages. You can > specify additional packages as an attribute on the > configuration element in the configuration file. > > > > > 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, 3:19 AM > > > > > > On Jun 20, 2011, at 5:04 PM, Gary Gregory wrote: > > > > > > On Jun 20, 2011, at 17:33, "ralph.goers > @dslextreme.com" > <ralph.go...@dslextreme.com<mailto:ralph.go...@dslextreme.com>> > wrote: > > > > > > 2.) is there an optional support for > ThreadContextClassLoader scenarios? > > This is often a problem for logging in libraries which > are on a shared classpath. Imagine 2 webapps, both using > OpenWebBeans as CDI container. One webapp sets the > org.apache.webbeans loglevel to debug, the other wone to > WARN ... > > > > As it currently stands, no, but I have always intended > to introduce something to support that. > > > > When I wrote the Log4j 2 API it took a stab at > creating an abstraction to bind the API to an > implementation. It was only when I built the core that I > added the plugin support. Looking at how it is done it now > occurs to me that the plugin support really should move to > the API and be used to bind to the implementation. This > would provide the flexibility needed to accomplish this. > > > > How much work us that? > > > > > > This shouldn't be much work at all. I'll probably do > it in the next few days. The only trick is the context > selection criteria and making sure the LoggerContext and > configuration are properly freed when the webapp shuts down. > Logback uses JNDI lookups (see > http://logback.qos.ch/manual/loggingSeparation.html#ContextJNDISelector) > as well as a Servlet Context Listener. I'll probably do > somethnig similar, although I'd prefer to do it with > annotations. > > Ralph > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
