On 21 Dec 2004, at 18:08, Richard Sitze wrote:
robert burrell donkin <[EMAIL PROTECTED]> 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 takesadvantageof 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
