commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [logging] JCL2.0 design - Architecture
Date Thu, 23 Feb 2006 06:11:34 GMT

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?

>>> 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 ;-)
> I believe that JVMs don't allow classes in java.* packages to be  
> loaded
> from anything but rt.jar.

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
> any literal output in the code at all. Having parameterised  
> messages as
> 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});

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:


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



View raw message