commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] ECL: pluggable message resolution
Date Tue, 21 Dec 2004 18:08:14 GMT
robert burrell donkin <> wrote on 
12/20/2004 02:51:17 PM:


> > ...  how do you propose to reconcile this "pluggable" mechanism
> > with the underlying logger that DOES accept "MSGID" and Object[] 
> > directly?
> >
> > I'm of the opinion that IF a reasonable proposal can be produced, then 

> > it
> > can be introduced at a later point in time [evolution].
> it seems to me that pluggability arises as a natural consequence.
> one day (i'm sure) it will be possible to create thin bridges to 
> i18nable logging systems. AFAIK none of the generations of logging 
> systems which JCL currently targets can be bridged in such a manner.
> it seems to me that the most elegant approach would be to allow (and 
> encourage) native thin bridges (to i18nable logging systems) but to 
> also build an implementation which would adapts from the enterprise 
> interfaces to base JCL. it would make sense for this implementation to 
> be pluggable (since the base rendering should ideally be minimally 
> sufficient) so that others can easily substitute a more sophisticated 
> rendering/i18n implementation.
> opinions?

I keep coming back to logging impls to which the wrappers pass the key and 
resource bundle name.  What does it mean to plug in an alternate mapping 
mechanism?  In such a scenario we do NOT want to translate before the 

Can anyone provide an example walk-through of what this means to the 
component developer, what resources and alternate resources the developer 
might provide, demonstrate the advantage this has?  I'm just not seeing 

Is the alternate mechanism by-component?

It's an interesting concept.  Lots of questions and issues.  I would agree 
that we don't want to do anything that would make this impossible, but 
neither do I want "fun cool" features to hold us back on other simple 
tasks that we can perform.

> >> And I'd like to see a Java 5 versiion of this interface that takes
> > advantage
> >> of variable argument lists, rather than the String[].
> >
> > Unlikely in the JCL.
> sad but true
> it would be quite a big step to say that the enterprise portion is for 
> java 5 only. i wouldn't actively object provided that active support 
> for this measure was adequately demonstrated.

An interesting question.

... if you are developing for Java 5 alone, it strikes me that you might 
be focusing on the logging classes provided?  I could argue that any Java 
5 application/framework could very well be required to deal with one 
component or another that leverages the JSR-47 logging anyway.


Richard A. Sitze
IBM WebSphere WebServices Development

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message