commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] ECL: pluggable message resolution
Date Mon, 20 Dec 2004 20:51:17 GMT
On 18 Dec 2004, at 20:18, Richard Sitze wrote:

> [forgive me for changing the subject, I'm trying to take steps to try 
> to
> help us focus on separate issues]
> "Noel J. Bergman" <> wrote on 12/17/2004 09:10:34 PM:
>> Richard Sitze wrote:
>>> As a real example, the axis community uses globalized messages.
>> A lot of products do, as I see on a regular basis, so I definitely
> support
>> your interest in this feature.
>> However, I view logging as separate from content generation.  I'd like
> to
>> see the mechanism pluggable.  That could be done by providing a 
>> message
>> factory to the logging layer, so that it does the lookup rather than
> your
>> example:
>>> log.error(Message.getMessage("MSGID", new String { arg1, ..., argN
> }));
>> Doing so would still permit your facade:
>>   log.error(this.getClass(), "thisMethodName", "MSGID", new String
> {...});
>> but the factory that the logger uses to construct the message would be
>> pluggable and distinct from the role of bridging to an underlying log
>> mechanism.
> I would claim that for a first shot let's keep this simple.  It is
> pluggable in that you may plug in your own Log implementation that does
> what you need.
> That aside, 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.


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

- robert

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

View raw message