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