The ClassLoader leaks should be preventable by using WeakReference/WeakHashmap or a similar construct.
This only got introduced in jdk-1.4.2 I think, so not sure if log4j-1.2 already use this feature. LieGrue, strub --- On Mon, 6/27/11, Jacob Kjome <[email protected]> wrote: > From: Jacob Kjome <[email protected]> > Subject: Re: log4j-2.0 questions > To: "Log4J Developers List" <[email protected]> > Date: Monday, June 27, 2011, 2:21 PM > > Log4j-1.2.x has the concept of separate logger repositories > distinguished using repository selectors. This allows a > single shared Log4j instance to serve up multiple distinct > logging configurations; one per/application. This can also > be achieved by using a separate instance of Log4j per/app. > Of course, that depends on how the classloader is > implemented. It only works for child-first, or > parent-last, classloading. > > Also note that distinguishing logger repositories by > classloader is not generally a good idea because then the > shared instance of Log4j ends up with a reference to a > classloader that might be destroyed if the app is > shutdown/restarted, but the appserver keeps running. > Tomcat will likely report this as a memory leak. Using > JNDI seems to be a better distinguisher. > > See the following for details on repository selectors in > Log4j-1.2.x. I don't know if a similar concept is planned > for Log4j-2.0? If so, some serious thought should go into > making it more robust and easier to use than in > Log4j-1.2.x. > > > http://wiki.apache.org/logging-log4j/AppContainerLogging > > > Jake > > On Tue, 21 Jun 2011 00:30:42 -0700 > Ralph Goers <[email protected]> > wrote: > > > > 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. > > > > After reading this again and thinking about your > question I'm thinking I must be taking this too literally. > Is what you are asking for that each webapp have its own set > of Loggers, Appenders, etc? I guess I don't understand > why each one would need its own implementation. What I would > envision is that each webapp would get its own LoggerContext > presumably on the Thread Context's ClassLoader and that the > Loggers and Configuration would be created using the > LoggerContext's class loader. > > > > 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]
