--- 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
|