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
|