(resuming an old thread... see http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111688890907693&w=2 for the history)
--- Simon Kitching <[EMAIL PROTECTED]> wrote: > On Mon, 2005-05-23 at 21:27 +0100, robert burrell <snip> > donkin wrote: > > > (e) > > > That we remove the weakref stuff that was added > since 1.0.4 (sorry, > > > Brian!). The problem is that having Log deployed > via the parent loader > > > and subclasses of Log (eg Log4JLogger) deployed > via the child > > > classloader creates exactly the situation that > renders the weakref stuff > > > useless. Instead, I would just document clearly > that people should use a > > > ServletContextListener in situations where > memory leaks matter. As I > > > describe below, I don't think it's all that > often. We could also provide > > > cut-and-paste code to help them create and > configure the > > > ServletContextListener - or maybe even bundle a > suitable implementation > > > in the commons-logging.jar file. > > > > i agree that ServletContextListener is the > preferred solution for web > > containers. i'd support an implementation shipping > in the optional jar. > > > > however, i do think that there are configurations > for other containers > > where the weak reference stuff may prevent or > reduce memory leaks. JCL > > has been widely (and rightly) criticised for > leaking memory in > > situations where this could have been avoided by > using weak references. > > we have code that addresses these criticisms. i > think we should ship it. > > I actually believe that JCL has been criticised for > leaking memory in > situations where *people who haven't analysed the > problem properly > believe weak references would solve the issue*. > > I don't believe that weakrefs *will* solve the > problem in those > situations. > > But I don't think the weakref stuff does any harm > either (as long as > there are no bugs in it!). So I'd be -0 to including > it, not -1. If the WeakHashtable stuff is going to stay, I'm wondering if it should be in the main jar. If it's in the optional jar we have to explain how to use it, which could easily be interpreted as implying it will solve memory leaks, which in many cases it won't. If we at the same time encourage using commons-logging-adapters.jar (which will defeat the WeakHashtable), well, let's just say I'll be looking forward to the Bile Blog entry :) The downside to having it in the main jar is it will be there by default, adding runtime overhead. I'm personally indifferent on this (even as to whether it stays at all), but thought the above was worth pointing out. Brian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
