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: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sun, 02 Jan 2005 20:23:25 GMT
On 27 Dec 2004, at 23:52, Ceki Gülcü wrote:

> On 2004-12-16 18:09:36, Richard Sitze wrote:
>
> > ok, without going back to review exactly what I said in an earlier 
> note, I
> > had in mind something like:
> >
> >   commons-logging-core.jar   - core interface & factory class, NO 
> config
> >   commons-logging.jar        - core + all helpers, NO config
> >   commons-logging-<impl>.jar - core + ONE helper, ONE config
> >
> > With this scheme, I believe we can scrub the code from LogFactory 
> that
> > looks for an attempts to load specific logger impls [Log4J, Avalon, 
> ?],
> > and instead depend entirely on the config.
>
> In commons-logging-<impl>.jar, I suppose by "ONE helper, ONE config"
> you mean the necessary wiring to let commons-logging know that it
> should use <impl> and skip automatic discovery. This simple and robust
> approach would probably alleviate many of the classloader problems
> users have been hitting.

i'm in definitely agreement with craig's assessment (a long while ago) 
that one of the fundamental flaws with the current JCL is that we ship 
an unusable API distribution with runtime dependencies.

as far as i'm concerned the only solution is to create a useable core 
API distribution with minimal portable configuration (system property 
only) and no discovery (except as required for backward compatibility 
in a combined distribution ie no classloader magic). upon configuration 
failure rather than throwing an exception, it should default to logging 
fatal and error messages to system.err.

IIUC the helper performs discovery and only one discovery helper can be 
picked by the fundamental configuration mechanism. this would indeed 
allow solutions to be provided for most of the most common troublesome 
use cases.

(apologies for prolonging the military metaphor.) i suspect that we 
might all be marching in the same direction now.  am i correct?

if so, then i do think it would work and i am confident that it can be 
done without breaking backwards compatibility.

- 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