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 Sat, 18 Dec 2004 20:18:08 GMT
[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 
> your interest in this feature.
> However, I view logging as separate from content generation.  I'd like 
> 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 
> 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].

> And I'd like to see a Java 5 versiion of this interface that takes 
> of variable argument lists, rather than the String[].

Unlikely in the JCL.

>    --- Noel

Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message