commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] ECL: pluggable message resolution
Date Sun, 02 Jan 2005 21:15:56 GMT

On 21 Dec 2004, at 18:08, Richard Sitze wrote:

> robert burrell donkin <robertburrelldonkin@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


Mime
View raw message