On Thu, 2006-02-23 at 17:11 +1100, Torsten Curdt wrote:
> On 23.02.2006, at 16:43, Simon Kitching wrote:
>
> > On Thu, 2006-02-23 at 13:10 +1100, Torsten Curdt wrote:
> >>> Agreed. How I see it working is:
> >>>
> >>> commons-logging-log4j.jar:
> >>> LogFactory tweaked to delegate to LogFactoryLog4j
> >>> LogFactoryLog4j - concrete subclass log LogFactory
> >>> Log -- standard Log interface
> >>> Log4JLogger -- implementation of Log interface for log4j
> >>>
> >>> commons-logging-jul.jar:
> >>> LogFactory tweaked to delegate to LogFactoryJUL
> >>> LogFactoryJUL - concrete subclass log LogFactory
> >>> Log -- standard Log interface
> >>> JULLogger -- implementation of Log interface for
> >>> java.util.logging
> >>>
> >>> commons-logging-dynamic.jar:
> >>> LogFactory tweaked to delegate to LogFactoryDynamic
> >>> LogFactoryDynamic : essentially the existing LogFactoryImpl
> >>> LogFactoryLog4j
> >>> Log4JLogger
> >>> LogFactoryJUL
> >>> JULLogger
> >>> ......
> >>>
> >>> Standalone applications, applets, embedded systems would use a
> >>> lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL
> >>> stuff,
> >>> no dynamic discovery stuff, only one logging adapter.
> >>
> >> And commons-logging-api.jar with the facade I assume
> >
> > No. Each of the jars above is stand-alone, because it includes
> > LogFactory and Log which are the public API to all JCL functionality
> > (the "facade"). They happen to include a slightly *different*
> > LogFactory.class file, but the binary interface is the same for each.
>
> Hm... so where would I declare a dependency against in my pom?
For an application, whichever logging lib you want to bundle with the
app.
For a library, any one of them will do. The commons-logging-noop.jar is
the simplest one so probably the most convenient. A user of the library
can then substitute any other jar they want instead.
Does that work for you?
> > Example:
> >
> > log.debugI18N(MsgKeys.KEYBOARD_ON_FIRE,
> > new Object[] {explosionDate, fireTemperature});
>
> sure ...although e.g. your english text could be the key
>
> So what I pointing to was the array vs parameter question
> ...or any other way around that. Actually something like
> that could work:
>
> log.parameter(value1).parameter(value2).debug(key)
>
> ...but we would need to create and return objects for that.
> Not sure if that's any better than the array approach. It's
> also the reverse order of what people are used to.
Yep. Need to think about that for a bit, but probably not going to fly
for both performance and usability. All options worth considering
though.
The main issue with this "array-of-params" stuff is that I'm not sure
about the performance of requiring an Object[] to be created in order to
invoke the log method (when the logging threshold may cause the contents
to be ignored anyway).
Another issue is the performance of the string interpolation required to
insert the params into the message.
And the final issue is that adding all this makes the Log API larger and
clumsier.
The final point is that this can be implemented at the user level
anyway, as long as i18n is not involved:
if (log.isDebugEnabled()) {
log.debug( MyUtils.createMessage("A {} occurred at {}", p1, p2) );
}
However it *is* convenient to have it in JCL core. And it's mandatory
*if* we support I18N logging in some manner.
> > The main problem with this is when JCL is used to bridge to an
> > underlying lib that doesn't support i18n. In this case, what do we do?
> > Implementing i18n inside JCL is not nice - JCL is supposed to be a
> > trivial adapter layer, not a logging implementation.
>
> agreed
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
