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 Tue, 24 May 2005 06:28:42 GMT

--- Simon Kitching <skitching@apache.org> wrote:

> On Mon, 2005-05-23 at 21:27 +0100, robert burrell
> donkin wrote:
> > > (b)
> > > That in addition to commons-logging.jar we
> distribute a
> > > "commons-logging-adapters.jar" which contains
> the entire contents of the
> > > "impl" subdirectory, ie all the logging adapters
> and the concrete
> > > LogFactory subclasses, but specifically NOT
> > >    * LogFactory
> > >    * Log
> > > 
> > > [this is along the lines of Brian's
> jar-refactoring proposal]
> > > 
> > > We should do away with commons-logging-api.jar;
> it serves no purpose.
> > 
> > -1
> > 
> > a few reasons:
> > 
> > 1. it is vital for dependency management. it is
> very important that JCL
> > ships a dependency free jar for compilation and
> dependency management.
> > the main flaw with the api is that it's too big
> and not viable by
> > itself. 
> 
> Sorry, I don't understand. Why can't people compile
> against
> commons-logging.jar?
> 
> > 
> > 2. it is useful for certain parent first
> configurations. replacing an
> > full jar with an api jar allows some parent first
> configurations to log
> > to log4j. 
> 
> I don't see why this would be true. What
> configurations does an api jar
> support that a full commons-logging.jar won't?
>
I believe it allows a child to use
commons-logging.properties to specify a logging
library that is not visible to the parent.  With only
the -api jar in the parent, the Log adapter will be
defined by the child and will thus be compatible with
the library.

See examples 10 and 10.i in 
http://xnet.wanconcepts.com/jcl/furtherAnalysis.html

> > 
> > 3. backwards compatibility. (would need a 1.1
> release at least.)
> 
> I'm happy with making the next release 1.1.
> 
> It should be totally backwards-compliant anyway.
> 
> 
> > > (c) 
> > > That we change the error message when multiple
> Log instances found, to
> > > state that child should contain -adapters.jar
> not full jar.
> > 
> > +1
> > 
> > we need to be confident about the diagnostics in
> this case before
> > recommended definite action. (i believe that some
> exotic classloader
> > configurations may also produce similar symptoms)
> i certain think that
> > the wording should be improved but would welcome a
> reference to
> > troubleshooting document (possibly an url?) which
> could provide more
> > explanation and could offer advice for the more
> exotic cases.
> 
> Yep, it's hard to be confident we've understood the
> situation completely
> until we get feedback from people in the field. But
> the fact that they
> can turn on diagnostics and email us the output
> should improve that
> situation greatly. 
> 
> As you say, we could be a bit careful about the
> wording of the error
> message, just in case it turns out that there are
> some other situations
> that trigger the same message...eg "This is probably
> caused by ..."
> 
> > 
> > > (d)
> > > That we provide the deployment instructions
> listed at the bottom of this
> > > email.
> > 
> > in some ways discovery deployment instructions are
> both needed and a
> > contradiction. discovery is supposed to guess
> right but sometimes it
> > needs a little help. 
> > 
> > JCL needs a troubleshooting document. (i even made
> a start on one a
> > while ago.) the deployment
> instructions/recommendations would fit very,
> > very into such a document. i like having
> information on the web (rather
> > than in release notes etc). not only is it easy to
> reference when
> > answering user questions but it's also easily
> indexed by search
> > engines. 
> > 
> > if this sounds like a good plan, i'll try to pull
> something along those
> > lines together in the next few days.
> 
> +1 
> 
> > 
> > > (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.
> 
> Regards,
> 
> Simon
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 


__________________________________________________
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