At 15:54 12.12.2002 -0800, Mark Womack wrote:
> One possible one-shot-kill-all-birds solution is to use the JNDI > space. See the updated version of http://www.qos.ch/logging/sc.html > (in particular JNDIRS). What do you think? > > I also suggested the JNDI solution in commons-dev in a somewhat > different context. It seemed to be well received.
First, it should be noted that "one-shot-kill-all-birds solution" was meant metaphorically. Birds are wonderful beings that should not be harmed. In general no animals should be harmed except perhaps mosquitoes. (I don't like mosquitoes.)
Should we consider adding the JNDIRS to v1.3 of log4j in a/the selectors package?
Yes, we can reasonably do that. However, I am unsure about the maturity of any of these approaches without proper testing/analysis. Consequently, we should include these selectors assuming that they are visibly marked as experimental. Their inclusion might spur Container developers to refine the selectors in a way only they can given their intimate knowledge of their own Container. For example, according to Adrian Brock (a key JBoss developer), JNDIRS will not work for MBeans because MBeans do not have a reserved JNDI java:/comp context. With his knowledge of JBoss, he came up with quite a complete, albeit sophisticated, solution. This was during a face to face conversation. I did not jot down the solution and I can't even begin to remember what it was. I am afraid that none of the selectors we propose in log4j proper will be universally applicable to all J2EE containers. Container developers will have to provide some level of support on their own. However, we can show part of the solution, letting Application servers/Web containers to fill in the rest. Coming back to the question, yes, we should create o.a.l.selectors but not ship it as part of the official distribution as the proposed selectors may be half-baked. Half-baked solutions eventually boomerang causing more harm than good. (I hope the above is not too confused.)
-Mark
-- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
