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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
