> 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.
I think that sounds reasonable for all the selectors we have proposed so far, given that each has specific limitations. We can document the entire package as experimental in the package.html, class javadoc, etc. > 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. So, do/should we expect to have the container implementors provide log4j solutions as part of their product or do we expect them to submit the solutions to the log4j project so that they can be distributed as part of the log4j distribution? Could we foresee an o.a.l.selectors.JBossSelector as part of the official log4j distribution and maintained by someone at JBoss? The code in the log4j servlet package will need a generic mechanism to know what repository selector class to use in the specific environment it is deployed within. It cannot assume any specific selector class like some solutions do today. Maybe we can do this as part of the servlet/context init params. > 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.) I understand. I will make the appropriate build changes to reflect this as we add the selector package. What else can we do to champion log4j RepositorySelector support in all the major J2EE containers? -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
