Re: [logging] JCL2.0 design - Architecture

[Torsten Curdt]

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


 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.

JULLogger -- implementation of Log interface for java.util.logging

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?

I had made the assumption that JCL would be
supporting java versions earlier than 1.4. I guess I should check,
but I

would think that the consensus is that we can't assume 1.4+ for JCL2.x

*shrug* for simple things like this there are always backports ;-)

from anything but rt.jar.

I believe that JVMs don't allow classes in java.* packages to be loaded

Doh! ...of course not! ...was obviously too late last night ;)

I also believe there would be legal issues with Apache issuing code that

is in a java.* package. The Apache MyFaces does release javax.faces.*
classes but it does have an explicit agreement with Sun.

So AFAIK there's no way to "backport" java APIs.

Some of the i18n ideas also need consideration.

Like that?

   debug("my i18n text in {}", new Object[]{language});

I don't see many options for i18n except having

   debug( final String pMessage, final Object pValue);
   debug( final String pMessage, final Object pValue1, final Object
pValue2);
   ...

in an interface which is really ugly. Pragmatic - but ugly ;)

No, not quite like that. The point of i18n support is *not* to encode

shown above is a prerequisite for this, but the "message" param has to
become a key.
Example:

  log.debugI18N(MsgKeys.KEYBOARD_ON_FIRE,
     new Object[] {explosionDate, fireTemperature});

any literal output in the code at all. Having parameterised messages as

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.

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

smime.p7s
Description: S/MIME cryptographic signature