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.
>
> > 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.
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});
There MsgKeys.KEYBOARD_ON_FIRE is a *key* that is used to look up the
real message text into which the parameters are then inserted.
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.
It looks to me like j.u.l's logging methods (eg Logger.warning) try to
use the message parameter first as a key into the logger's resource
bundle (possibly inherited from its parent), and as a literal string if
that fails. Log4j, on the other hand, has different methods for i18n vs
literal messages. JCL would therefore *have* to support the log4j
approach, otherwise we would never know which log4j method to invoke.
All interesting issues to ponder...
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
