You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2005/01/02 21:23:25 UTC
Re: [logging] Enterprise Common Logging... dare we say 2.0?
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
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 3 Jan 2005, at 17:03, Ceki Gülcü wrote:
> At 05:53 PM 1/3/2005, robert burrell donkin wrote:
>
>> nope (but don't ask me to find the references). distributing an api
>> jar which requires runtime dependencies was a mistake. this issue
>> hasn't arisen for quite a while since we try to keep quiet about the
>> existing of the api jar.
>
> I do not understand. How can JCL *not* require runtime dependencies
> given that it is a wrapper around various logging APIs? In other
> words, how can JCL wrap API x without runtime dependencies on API x?
a minimal core should have robust behaviour when deployed without any
support (rather than die horribly). for example, IIRC log4j prints up a
message to System.err and then silently swallows all messages when it
cannot configure itself.
JCL core should do something similar (though i'd advocate logging fatal
- and possibly error level messages - to System.err for the reasons
explained well in james strachan's blog
http://radio.weblogs.com/0112098/2004/10/06.html).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:53 PM 1/3/2005, robert burrell donkin wrote:
>nope (but don't ask me to find the references). distributing an api jar
>which requires runtime dependencies was a mistake. this issue hasn't
>arisen for quite a while since we try to keep quiet about the existing of
>the api jar.
I do not understand. How can JCL *not* require runtime dependencies given
that it is a wrapper around various logging APIs? In other words, how can
JCL wrap API x without runtime dependencies on API x?
>- robert
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 3 Jan 2005, at 16:25, Ceki Gülcü wrote:
> At 09:23 PM 1/2/2005, robert burrell donkin wrote:
>
>> 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.
>
> Robert,
>
> Are you by any chance referring to Craig's comments [1] on the
> "commons-logging & classloading" thread [2]?
nope (but don't ask me to find the references). distributing an api jar
which requires runtime dependencies was a mistake. this issue hasn't
arisen for quite a while since we try to keep quiet about the existing
of the api jar.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:23 PM 1/2/2005, robert burrell donkin wrote:
>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.
Robert,
Are you by any chance referring to Craig's comments [1] on the
"commons-logging & classloading" thread [2]?
[1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=106608349829350&w=2
[2] http://marc.theaimsgroup.com/?t=106329040800001&r=1&w=2
>- robert
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org