>> 1. we absolutely need removal of the log4j classpath entries > > > The Log4J classpath entries were remnoved prior to the 1.0.3 release of > Commons Logging. What version are you working with?
Looks like we are working with 1.0.3, which was released on April the 7th; classpath entries were removed on April the 17th, so we still have them... We just discovered that you already removed them, so by removing them in JPackage we'll be moving closer to the original, not further :)
>> 2. we'd like the build-in backends split from the main jar so we can >> made them optional and allow people not to install them if they already >> have log4j or a 1.4 jvm. > > > In the specific case of commons-logging and Log4J, that suggestion (which > led to the existence of commons-logging-api.jar) has been an absolute > disaster. Remember that the commons-logging library is supposed to (and > does, at least with 1.0.3) dynamically adapt to whether Log4J is present > or not. If Log4J is not available, the default behavior will operate > correctly, with NO need for separating the Log4J-specific implementation > classes.
It is that default behavior - SimpleLog - that is the target of this separation from the rest of the commons-logging. I think that such a separation will cause even bigger disaster, because unconfigured log4j will be used by default, and all logging will cease...
About commons-logging-api.jar/commons-logging.jar: it seems that one is a superset of the other, and not a complement. I wonder why...
Also: will this separation be eliminated?
>> 3. people have asked for further splittage of the backend glue so they >> can only install the parts relevant to the backend they'll actually use > > > As a very-very-very long time Java developer, and a primary contributor to > many Apache projects (including Tomcat and Struts), I strongly suggest > that you push back on the users asking for this -- they're not > understanding the real issues involved. If we did what they want, it's > not really going to solve the problems they think they have.
Craig, I am the people in question :) I did not suggest that to solve any problems I am having, but as a separation more meaningful, IMHO, than the separation of SimpleLog from the commons-logging APIs... I gather you are strongly against separating glue from the interface :) Can you please hint at what *are* the real issues involved, so that I can learn from your experience? Wasn't the split c-l-api/c-l such a separation (albeit not as fine-grained)?
And in general, if I have provider-based architecture where each provider is actually a proxy/adaptor to an existing service, why must all available adaptors be bundled with the generic interface classes, and not with the corresponding services/adaptees - or completely unbundled?
Respectfully,
Leonid Dubinsky.
P.S. Thanks for everything, including JSF! D.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
