logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: log4j-2.0 questions
Date Wed, 29 Jun 2011 20:51:49 GMT
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.goers@dslextreme.com> wrote:

> From: Ralph Goers <ralph.goers@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.goers@dslextreme.com>
> wrote:
> > 
> > From: Ralph Goers <ralph.goers@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.goers@dslextreme.com<mailto:ralph.goers@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message