commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [jcl] mocks
Date Sun, 11 Dec 2005 09:17:37 GMT
On Sun, 2005-12-11 at 07:53 +0100, Torsten Curdt wrote:
> >> Basically all it holds is the Log interface and
> >> the LogFactory providing an Log implementation
> >> that is doing nothing.
> >
> > The existing jar already provides NoOpLog.jar. Providing a
> > commons-logging.properties file, or setting the appropriate system
> > property, ensures that no-op logging is used (the default is SimpleLog
> > that just writes to stdout).
> 
> What "NoOpLog.jar"? I know there is a NoOpLog implementation
> but that's not the point. Some people just don't want the
> dependency. 

dependencies should be declared against the API and not the
implementation. IMO the biggest mistake made with JCL was that the API
jar is not runnable. creating a new NoOp jar and declaring a dependency
upon it is positively wrong since that will mess up dependency
management graphs.

the api jar is now used not only as the basic JCL dependency but also
for complex classloader configurations. it's actually a special jar
arranged to allow JCL to be deployed in various classloader setups. IMO
this was the second fatal mistake in the development of JCL. 

what's really needed is not a NoOp jar but a jar that's runs containing
definitions of the core API (Log and LogFactory) without anything else.
(i've taken a look before at creating such a beast and found it
difficult.) 

but that actually satisfy your downstream users?

FWIW distributing a combined library with a NoOp implementation may well
cause problems with any application using JCL. the possible known
classloading configurations would need to be analysed carefully or the
presence of NoOp in the classloader hierarchy may well cause problems.
IMO it would be more robust to use byte code enhancement to swallow all
logging calls (if that's what your downstream customers really want). 

> And they also don't want to care about a property
> file. Instead of everyone providing this mini-jar it would be
> nice to have it with JCL IMO.
> 
> Even better I like the idea of having a static selection of the
> underlying log system. So having several jars
> 
>   commons-logging-[version]-log4j.jar
>   commons-logging-[version]-noop.jar
>   ...
> 
> would be a good alternative. Like that.

this is ceki's preferred solution. i prefer dynamic binding (run an
enhancer against the library in question which does the same job).

unfortunately, as far as i can tell, a proper implementation is not
possible without breaking backwards compatibility. 

thanks to hard work by simon and brian, the current JCL is known to be
much better than any before. we have a matrix of possible classloader
configurations and those which the specifications allow to be solvable
appear to work ok now.

this does not address the fundamental problems but i think these are
better understood now:

1 the J2EE classloader specification is broken, very broken. for
political reasons, it's not going to be fixed anytime soon. JCL was
coded in the servlet era by folks who are acknowledged experts in the
servlet and java 2 specifications. JCL would have worked fine if
everyone followed the Java 2 and servlet classloading specifications.
unfortunately, since the J2EE specification is broken, JCL cannot work
correctly. this cannot be fixed until the specification and every
container is fixed. static binding (whether done with different jars or
using byte code enhancement) does not have this limitation.

2 the very popularity of JCL is a major problem. with knowledge and
correct configuration, the latest JCL will fail to work in a vanishingly
small number of real life situations. unfortunately, very few users have
the knowledge of classloaders required to fix broken configurations and
the popularity of JCL means that the jar has a habit of findings it's
way into very difficult classloaders (for example, system classloaders).
these are very hostile environments. this problem will not be fixed by a
movement to static binding.

3 IMHO the basic usage pattern for JCL suggested in the early days is
problematic. 

private static Log log = LogFactory.getLog() 

is very widely used and suitable for applications but is difficult for
bricks:

3a static utilities should not require logging
3b object libraries should allow themselves to be adapted to the logging
system of their host and therefore the log instance should be an
instance variable (not a class variable). this poses a difficulty:
logging is usually seen as a framework issue and possibly not exposed as
part of the public API. Joerg and Jörg have a solution in mind for this
but it's on hold until the 1.1 release is cut.

BTW i've been having problems with my ISP all week but hopefully i'm
back online now. 

i can make time for JCL but i really need some more eyes on what is a
difficult problem. 

volunteers?

- robert


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