commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <bes_commons_...@yahoo.com>
Subject Re: [logging] proposed design for 1.0.5
Date Fri, 17 Jun 2005 06:09:21 GMT
(resuming an old thread... see
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111688890907693&w=2
for the history)

--- Simon Kitching <skitching@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message