Howdy, >If we think it is a good, useful example of a repository selector, and to >be useful it needs to live at the same location as the log4j jar, why >should we not include it in the official distribution? When does it become >"core", in >your opinion? In my mind, it may be possible that the log4j includes >several different, useful repository selectors, each with their own use, >maybe in their own package o.a.log4j.selectors or something.
It becomes core when it has: - Been part of the contrib distribution (or its own log4j add on, or however it's packaged) for a bit. - Been tested more extensively, preferably with test cases that are part of the distribution. - Been used by people, and hopefully generated some questions and discussions on the user mailing list. I don't doubt the quality of the code. I do think it's a bit specific (to tomcat 4.x) right now, and that may need tweaking, or alternatively we may need to write JBoss/Resin/Weblogic/whatever selectors, or maybe a more universal JNDI repository selector like Ceki suggested. I also think it's a bit new, and I want to maintain log4j's reputation of outstanding stability and reliability. Accordingly, I think it should be its own jar, with the stipulations that: - It's new - It's experimental - It needs to be in the same class loader as log4j.jar - It hasn't been tested on anything other than tomcat 4.x - We want feedback on it This type of issue is always open to interpretation, but I'd rather err on the conservative side before throwing things into the log4j core package. Yoav Shapira Millennium ChemInformatics -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
