Re: [logging] ECL: pluggable message resolution

[robert burrell donkin]

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" <[EMAIL PROTECTED]> 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.

opinions?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]