Simon Kitching <[EMAIL PROTECTED]> writes:
>So perhaps we could build two separate jars from mostly-common source
>code? Deploying the traditional commons-logging jar would do the "be
>quiet on no config", while the "enterprise" commons-logging jar would do
>something like "write message to STDERR then throw a runtime exception
>on no config"?
Hm. This does not feel right to me. IMHO this will lead to the
situation that some developers (most notably the log4j guys; Hi Ceki!
[1]) condemn. Your web app container (let's say tomcat) ships with the
"missing config is ok" jar version in its class path and your
application is deployed with the "missing config is bad"
version. Leading to all kinds of interesting classloader issues and
general nightmarish behaviour.
Regards
Henning
[1] If we went down the path that Ceki has for years lobbied for,
today it would be "tomcat ships with log4j 1.2.x and your app requires
log4j 1.3.x,, leading to all kinds of interesting classloader issues
and general nightmarish behaviour." today... :-)
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
