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 Mon, 18 Jul 2011 12:04:56 GMT
Hi Ralph!

I'll try it out in a few projects today.

LieGrue,
strub

--- On Mon, 7/18/11, Ralph Goers <ralph.goers@dslextreme.com> wrote:

> From: Ralph Goers <ralph.goers@dslextreme.com>
> Subject: Re: log4j-2.0 questions
> To: "Ralph Goers" <Ralph.Goers@dslextreme.com>
> Cc: "Log4J Developers List" <log4j-dev@logging.apache.org>
> Date: Monday, July 18, 2011, 4:14 AM
> I've committed the code that
> implements ContextSelectors.  All the unit tests work
> but I am still testing with different app servers.  The
> ClassLoaderContextSelector seems to work OK but it needs a
> lot more testing to determine where it will have problems. I
> believe it will deal with static Loggers properly since they
> will be owned by the LoggerContext that is associated with
> the ClassLoader of the class that created them. The one
> downside to it is that wrapper implementations of LogManager
> have to provide their fully qualified class name so that the
> class that is trying to obtain the Logger can be determined
> .  That should be working properly in the SLF4J, Log4j
> 1.2 and JCL bindings as well as the Log4J 2.0 bindings.
> 
> I haven't really tested the JNDIContextSelector yet and
> have done nothing with OSGi as I'm not sure what it needs.
> 
> I still haven't gotten locating the configuration from a
> URL or file location completely done. I also added the start
> for support of automatic reconfiguration.
> 
> Ralph
> 
> 
> On Jul 12, 2011, at 8:00 AM, Ralph Goers wrote:
> 
> > It is obviously too early in the morning for me. 
> I haven't committed the code yet, but the
> ClassLoaderContextSelector uses a ConcurrentHashMap where
> the key is the ClassLoader (which I plan to change to value
> returned by the toString method) and the value is a weak
> reference to the LoggerContext. So, although the key still
> exists in the Map the context itself should be garbage
> collected when the ClassLoader is cleaned up.  Every
> time I look at the Servlet Filters and Listeners that are
> required to make the JNDI stuff work I get myself confused
> because they don't work properly with the
> ClassLoaderContextSelector.
> > 
> > 
> > On Jul 12, 2011, at 7:40 AM, Ralph Goers wrote:
> > 
> >> 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
> 
> 

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