Hi Ralph! I'll try it out in a few projects today.
LieGrue, strub --- On Mon, 7/18/11, Ralph Goers <[email protected]> wrote: > From: Ralph Goers <[email protected]> > Subject: Re: log4j-2.0 questions > To: "Ralph Goers" <[email protected]> > Cc: "Log4J Developers List" <[email protected]> > 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 <[email protected]> > wrote: > >>> > >>>> From: Ralph Goers <[email protected]> > >>>> Subject: Re: log4j-2.0 questions > >>>> To: "Log4J Developers List" <[email protected]> > >>>> 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 > <[email protected]> > >>>> wrote: > >>>>> > >>>>>> From: Ralph Goers <[email protected]> > >>>>>> Subject: Re: log4j-2.0 questions > >>>>>> To: "Log4J Developers List" <[email protected]> > >>>>>> 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
