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.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: 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.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, 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-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
