commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] proposed design for 1.0.5
Date Tue, 24 May 2005 06:51:42 GMT
On Mon, 2005-05-23 at 23:28 -0700, Brian Stansberry wrote:
> --- 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
> 

Ecch!
So it isn't a compile issue, only a runtime issue. And it applies only
when parent-first classloading is selected.

In this case, LogFactoryImpl looks for XXLogger in the child
classloader, but the child delegates back up to the parent classloader,
so XXLogger gets loaded there. Then XXLogger can't find the actual
library. Not having XXLogger in commons-logging-api.jar forces it to be
found in the child even when parent-first loading order was selected.
And the XXLogger class can then find its concrete implementation.

You know my opinion of parent-first classloading - people who select
this deserve all they get. And if people really want to handle this
case, they should be able to write their own trivial subclass of
Log4JLogger, and point to that with the commons-logging.properties (nb:
haven't tested this). That way, there's *definitely* no matching class
in commons-logging.jar

So I'm -0 on providing commons-logging-api.jar. It's a workaround for
user stupidity, with an alternative solution available. I think removing
the confusion between commons-logging.jar and commons-logging-api.jar is
well worth doing.




By the way, when replying to an email, would you mind removing the bits
not relevant to your reply? I don't mean removing stuff that's needed to
understand the reply, just bits that the reply isn't addressing at all.
And guff like all the signatures that build up at the bottom of the
mail. This saves bandwidth, archive space, and makes reading the email
easier. Thanks.

Regards,

Simon


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