commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
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" <noel@devtech.com> 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].


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

> 
>    --- Noel


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message