You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2006/01/20 02:02:15 UTC

[logging] minimal jar vs api jar

Re the proposed "minimal" jarfile:

What exactly are the differences between this and the existing
commons-logging-api jarfile?

As far as I can see, commons-logging-api.jar has the Jdk14Logger class
in it, but otherwise is dependency-free.

I vaguely remember comments about api "being a mistake because it's not
usable out of the box" (I may have that quote wrong). However it looks
ok to me. Here's the contents from release 1.0.3:

simon@blackbox:~/apache/commons-logging-1.0.3$ jar tf
commons-logging-api.jar
META-INF/
META-INF/MANIFEST.MF
org/
org/apache/
org/apache/commons/
org/apache/commons/logging/
org/apache/commons/logging/impl/
org/apache/commons/logging/impl/Jdk14Logger.class
org/apache/commons/logging/impl/LogFactoryImpl$1.class
org/apache/commons/logging/impl/LogFactoryImpl.class
org/apache/commons/logging/impl/NoOpLog.class
org/apache/commons/logging/impl/SimpleLog$1.class
org/apache/commons/logging/impl/SimpleLog.class
org/apache/commons/logging/Log.class
org/apache/commons/logging/LogFactory$1.class
org/apache/commons/logging/LogFactory$2.class
org/apache/commons/logging/LogFactory$3.class
org/apache/commons/logging/LogFactory.class
org/apache/commons/logging/LogConfigurationException.class
org/apache/commons/logging/LogSource.class
META-INF/LICENSE.txt

The only differences I can see between this and the proposed "minimal"
are:
 * add WeakHashtable
 * remove Jdk14Logger

Can't we just make those changes to the api jar?

Regards,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] minimal jar vs api jar

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-01-22 at 10:36 +1300, Simon Kitching wrote:
> On Sat, 2006-01-21 at 16:41 +0000, robert burrell donkin wrote:
> > On Fri, 2006-01-20 at 14:02 +1300, Simon Kitching wrote: 
> > >
> > IMO the mistake was in creating API classes (Log and LogFactory) which
> > could not be used independently. the static methods should delegate to a
> > single LogFactory implementation. any tricks with classloaders should
> > have been delegated to LogFactoryImpl. 
> > 
> > > However it looks
> > > ok to me. Here's the contents from release 1.0.3:
> > >
> [snip]
> >  
> > > 
> > > The only differences I can see between this and the proposed "minimal"
> > > are:
> > >  * add WeakHashtable
> > >  * remove Jdk14Logger
> > > 
> > > Can't we just make those changes to the api jar?
> > 
> > +1
> > 
> > good point: the API jar started out with a lot less in. 
> 
> Can we get away with removing jdk14Logger from this jar?
> 
> I think we can; people who really want the jdk14logger can move to the
> full jarfile. That's not really a "backwards compatibility" issue,
> because they are already willing to overwrite a jarfile with a new one
> if they are upgrading to 1.1.
> 
> Comments?

should be ok but i'd feel better if we tested it. anyone fancy
volunteering to test the behaviour of JCL in this new configuration?

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] minimal jar vs api jar

Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2006-01-21 at 16:41 +0000, robert burrell donkin wrote:
> On Fri, 2006-01-20 at 14:02 +1300, Simon Kitching wrote: 
> >
> IMO the mistake was in creating API classes (Log and LogFactory) which
> could not be used independently. the static methods should delegate to a
> single LogFactory implementation. any tricks with classloaders should
> have been delegated to LogFactoryImpl. 
> 
> > However it looks
> > ok to me. Here's the contents from release 1.0.3:
> >
[snip]
>  
> > 
> > The only differences I can see between this and the proposed "minimal"
> > are:
> >  * add WeakHashtable
> >  * remove Jdk14Logger
> > 
> > Can't we just make those changes to the api jar?
> 
> +1
> 
> good point: the API jar started out with a lot less in. 

Can we get away with removing jdk14Logger from this jar?

I think we can; people who really want the jdk14logger can move to the
full jarfile. That's not really a "backwards compatibility" issue,
because they are already willing to overwrite a jarfile with a new one
if they are upgrading to 1.1.

Comments?

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] minimal jar vs api jar

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2006-01-20 at 14:02 +1300, Simon Kitching wrote: 
> Re the proposed "minimal" jarfile:
> 
> What exactly are the differences between this and the existing
> commons-logging-api jarfile?
> 
> As far as I can see, commons-logging-api.jar has the Jdk14Logger class
> in it, but otherwise is dependency-free.
> 
> I vaguely remember comments about api "being a mistake because it's not
> usable out of the box" (I may have that quote wrong). 

no - that's a fair statement of my opinions 

IMO the mistake was in creating API classes (Log and LogFactory) which
could not be used independently. the static methods should delegate to a
single LogFactory implementation. any tricks with classloaders should
have been delegated to LogFactoryImpl. 

> However it looks
> ok to me. Here's the contents from release 1.0.3:
> 
> simon@blackbox:~/apache/commons-logging-1.0.3$ jar tf
> commons-logging-api.jar
> META-INF/
> META-INF/MANIFEST.MF
> org/
> org/apache/
> org/apache/commons/
> org/apache/commons/logging/
> org/apache/commons/logging/impl/
> org/apache/commons/logging/impl/Jdk14Logger.class
> org/apache/commons/logging/impl/LogFactoryImpl$1.class
> org/apache/commons/logging/impl/LogFactoryImpl.class
> org/apache/commons/logging/impl/NoOpLog.class
> org/apache/commons/logging/impl/SimpleLog$1.class
> org/apache/commons/logging/impl/SimpleLog.class
> org/apache/commons/logging/Log.class
> org/apache/commons/logging/LogFactory$1.class
> org/apache/commons/logging/LogFactory$2.class
> org/apache/commons/logging/LogFactory$3.class
> org/apache/commons/logging/LogFactory.class
> org/apache/commons/logging/LogConfigurationException.class
> org/apache/commons/logging/LogSource.class
> META-INF/LICENSE.txt
> 
> The only differences I can see between this and the proposed "minimal"
> are:
>  * add WeakHashtable
>  * remove Jdk14Logger
> 
> Can't we just make those changes to the api jar?

+1

good point: the API jar started out with a lot less in. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] minimal jar vs api jar

Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2006-01-21 at 17:05 +0000, robert burrell donkin wrote:
> On Sat, 2006-01-21 at 00:09 +1100, Torsten Curdt wrote: 
> > On 20.01.2006, at 12:02, Simon Kitching wrote:
> > 
> > > Re the proposed "minimal" jarfile:
> > >
> > > What exactly are the differences between this and the existing
> > > commons-logging-api jarfile?
> > 
> > Basically the implementations.
> > 
> > It would be nice if you could satisfy the commons-logging dependency
> > by just having the API jar in the classpath. But this also means no
> > implementations and no configuration. Basically it should not log at
> > all.

Can't you just use commons-logging-api.jar and a
commons-logging.properties file that specifies the NoOpLog logger?

=======
# commons-logging.properties file: disable all logging
org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLogger
=======

This properties file just needs to be in the classpath (including inside
a jarfile).

Regards,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] minimal jar vs api jar

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2006-01-21 at 00:09 +1100, Torsten Curdt wrote: 
> On 20.01.2006, at 12:02, Simon Kitching wrote:
> 
> > Re the proposed "minimal" jarfile:
> >
> > What exactly are the differences between this and the existing
> > commons-logging-api jarfile?
> 
> Basically the implementations.
> 
> It would be nice if you could satisfy the commons-logging dependency
> by just having the API jar in the classpath. But this also means no
> implementations and no configuration. Basically it should not log at
> all.

IMHO this is a different and distinct issue. the particular concern
which prompted this discussion was about dependency management for
downstream rebundlers. the api jar has enough in it to function
reasonably and so the particular issue can be resolved by adding more
documentation.

<snip>

> > org/apache/commons/logging/impl/
> > org/apache/commons/logging/impl/Jdk14Logger.class
> > org/apache/commons/logging/impl/LogFactoryImpl$1.class
> > org/apache/commons/logging/impl/LogFactoryImpl.class
> > org/apache/commons/logging/impl/NoOpLog.class
> > org/apache/commons/logging/impl/SimpleLog$1.class
> > org/apache/commons/logging/impl/SimpleLog.class
> 
> Why? 

history :-/

> ...it's meant to be an API jar!?

i agree that the api jar we distribute has it's drawbacks but these
spring from fundamental choices which have been baked in by backwards
compatibility. 

i've had chance to think over possible approaches to finding a home for
code that does what drools want. i think that the best approach would be
to create a separate component here in the commons. however, this isn't
my top priority right now so some one would need to step up if it's
going to happen any time soon...

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] minimal jar vs api jar

Posted by Torsten Curdt <tc...@apache.org>.
On 20.01.2006, at 12:02, Simon Kitching wrote:

> Re the proposed "minimal" jarfile:
>
> What exactly are the differences between this and the existing
> commons-logging-api jarfile?

Basically the implementations.

It would be nice if you could satisfy the commons-logging dependency
by just having the API jar in the classpath. But this also means no
implementations and no configuration. Basically it should not log at
all.

> As far as I can see, commons-logging-api.jar has the Jdk14Logger class
> in it, but otherwise is dependency-free.

It's not the dependency that is the point.

Let's take drools as an example. They don't really want to use JCL
but they want to use jci. Now jci uses JCL. But they don't really
care about the jci logging. And even more important they don't want
to tinker with a JCL configuration. Basically they want the logging
to be removed or being a NOP operation in libraries.

Basically that was the idea for the minimal JCL. You use the minimal
one. In case you need the logging you can replace it with the full
one and configure JCL.

> org/apache/commons/logging/impl/
> org/apache/commons/logging/impl/Jdk14Logger.class
> org/apache/commons/logging/impl/LogFactoryImpl$1.class
> org/apache/commons/logging/impl/LogFactoryImpl.class
> org/apache/commons/logging/impl/NoOpLog.class
> org/apache/commons/logging/impl/SimpleLog$1.class
> org/apache/commons/logging/impl/SimpleLog.class

Why? ...it's meant to be an API jar!?

> Can't we just make those changes to the api jar?

Sure, I would prefer to fix the API jar.

cheers
--
Torsten