logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: log4j-2.0 questions
Date Tue, 12 Jul 2011 14:40:34 GMT
I've spent days screwing around with this and thinking about it.  Creating a LoggerContext
per classloader and then assigning the Loggers to the correct LoggerContext is pretty easy.
 However, a few issues arise: 1. How to allow the LoggerContexts to be flexibly configured,
2. How to treat the parent/child relationship that exists with ClassLoaders (as far as configuration
is concerned) and, 3. How to remove a LoggerContext when its associated ClassLoader is being
removed do to the application being undeployed.

I want to make sure that several scenarios are adequately solved for:
1. A simple application that just needs a single LoggerContext.
2. A simple web application with its own LoggerContext and configuration.
3. A set of web applications that share a common configuration. This has two variations. 
	a. All the applications are in an EAR.
	b. The common configuration is at the container level.
4. Similar to 3a, an EAR containing EJBs and WARs.
5. OSGi (having limited experience with OSGi this is definitely at the bottom of my list).

Solving for these using JNDI allows for redeployment and is fairly simple to implement, but
it does have the problem of Loggers obtained by classes from parent ClassLoaders being associated
with the LoggerContext that is being undeployed.  The ClassContextContextSelector allows LoggerContexts
to always be associated with a ClassLoader and  then have Loggers associated with the ClassLoader
of the class that called getLogger(), but I don't know of a way to detect that a ClassLoader
is being released and so the LoggerContext should be removed.

Ralph



On Jun 30, 2011, at 12:14 AM, Mark Struberg wrote:

> Hi Ralph!
> 
> Yes, the static loggers would be important to solve. It's just not acceptable that a
client library needs to take care of this problem
> 
> That's why I thought that there are different strategy implementations:
> 
> * OSGi
> * TCCL
> * JNDI (which is imo pain slow)
> 
> The problem here is that we also need this info to determine if we should log at all,
so it really gets executed with each and every log.debug and log.trace too. But most times
it's the users (=programmers) fault. Doing 10 millions of log.debug per second in a proxy
is just not sane ;)
> 
> Maybe we could pickup this logger-strategy only if the configuration is in the same classloader
or in a higher-level classloader?
> 
> It should be possible to implement own strategies which could be used by app-servers
like JBoss to adopt it to their classloading strategy.
> 
> makes sense?
> 
> LieGrue,
> strub
> 
> 
> --- On Thu, 6/30/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: Thursday, June 30, 2011, 12:33 AM
>> OK - that is what I thought.  I
>> have the innards of that working now and have a decent
>> solution for Tomcat. But I need to do more work on it as the
>> way the various app containers handle ears makes that a bit
>> of a pain and for that I expect JNDI may be the only good
>> solution. I also don't use EJBs at all so I don't have
>> support for that yet, although my understanding is that EJB
>> 3 provides some features that could help in this.
>> 
>> FWIW, I've also considered the "unsolvable" problem of
>> static loggers that come from classes in parent
>> classloaders. I actually have something that will work quite
>> nicely in Tomcat but almost certainly won't work in JBoss or
>> other app servers, again due to the various ways those
>> containers deal with class loaders for enterprise
>> applications.  I took a look at JULI last night and
>> Tomcat is doing some interesting things in there but I think
>> what they are doing may only work in Tomcat.
>> 
>> Ralph
>> 
>> On Jun 29, 2011, at 3:40 PM, Mark Struberg wrote:
>> 
>>> [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.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, 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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 


---------------------------------------------------------------------
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