You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Richard Sitze <rs...@us.ibm.com> on 2004/12/18 21:18:08 UTC
RE: [logging] ECL: pluggable message resolution
[forgive me for changing the subject, I'm trying to take steps to try to
help us focus on separate issues]
"Noel J. Bergman" <no...@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
Re: [logging] ECL: pluggable message resolution
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 21 Dec 2004, at 18:08, Richard Sitze wrote:
> robert burrell donkin <ro...@blueyonder.co.uk> wrote on
> 12/20/2004 02:51:17 PM:
>
> <snip/>
>
>>> ... 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
> logger.
+1
i do think that in order to ensure that JCL enterprise (JCLE) works
off-the-shelf we need a truly minimal bridging component from JCLE to
JCL which can be used as a minimal implementation. this would ensure
that components logging to JCLE could function in a JCL-only
environment.
by native implementations, i mean direct JCLE -> i18nable logging
system bridges. components would be needed to provide these as well.
it would be good to provide a component that provided a sophisticated
i18 bridge to JCL possibly depending on additional i18n component(s).
some sort of discovery system would need to decide which bridge to plug
in (as happens in JCL).
> 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
> this.
i would see this as purely transparent. the key and parameters are
passed to JCLE. some sort of configuration and discovery finds the
bridge to use and calls it. the bridge then (in the case of native
i18n) passes the key and message onwards or (otherwise) performs the
localization and passes the results to a standard JCL bridging adapter.
> 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.
i do think some kind of minimal implementation is needed.
>>>> 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.
there are some nice features which are (or will be) provided by log4j
but not by JSR-27 logging. however, your argument works equally well
whether it's for JSR-47 or log4j (since JCL will always be in some ways
a common denominator).
the principle reason why people even using java 5 would still want to
use commons logging is for the same reason it was developed: creating
independent components. if you ship a server side application where you
see yourself as having only limited control over the environment or
equally, wishing to sell to a variety of customers each with specific
logging requirements, then using JCL should allow the source to remain
unchanged.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: pluggable message resolution
Posted by Richard Sitze <rs...@us.ibm.com>.
robert burrell donkin <ro...@blueyonder.co.uk> wrote on
12/20/2004 02:51:17 PM:
<snip/>
> > ... 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
logger.
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
this.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] ECL: pluggable message resolution
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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" <no...@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].
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org