At 06:02 PM 1/19/2005 +0100, you wrote: >At 12:49 AM 1/19/2005, Jacob Kjome wrote: > >>of course if you have the authority to add log4j.jar to the server's >>classpath, >>why wouldn't you have the authority to add other jars there as well? > >That's an extremely interesting point. Although you could place other >jar files along with log4j-(core).jar, the idea is to avoid placing >application specific jars high in the class loader tree. For instance, >if log4j-db.jar were placed alongside log4j-(core).jar, you would also >need to place the associated JDBC drivers alongside the log4j jars. > >If on the other hand log4j-db.jar was bundled within the >web-application's WAR file, then the required JDBC files could also be >bundled or encapsulated within the web-app. >
Yes, and if you do this and try using container-managed connection pooling, you will get class cast exceptions if you put your DB driver in WEB-INF/lib.... assuming you are using child-first classloading behavior. This is one reason why most servers don't do this by default. It can cause problems if you are not careful. Personally, I see connection pooling as a container thing and I never ever add the DB driver to WEB-INF/lib for this reason.
>>Ceki, you *always* assume that child-first classloading behavior will be
>>available, and this just isn't always true. In fact, Java2 classloading
>>behavior is the default for pretty much every appserver I can think of other
>>than Tomcat. Some provide the *option* to trigger child-first behavior,
>>but in
>>many cases it is not very well supported. Tomcat is the only real example of
>>this being a viable option.
>
>Point well taken. In case a web-app needs logg4j version X and the
>server provides some incompatible version Y under the Java2 delegation
>scheme, then unless the server can be instructed to use the delegation
>scheme specified in the Servlet Specification, the only remaining
>solution is to remove version Y from the server. Keeping BWC would at
>least guarantee that the server administrator could always safely
>replace an older version of log4j with a new one.
>
BWC? Did you forget the "A" for "Boundary Waters Canoe Area"? :-)
>> > >Anyways, as long as you can bundle what you want with your app, I'm happy.
>> >
>> > Bundling log4j.jar with your web-app will still be an option. However,
>> > it will no longer the *only option.
>> >
>>
>>...Under Tomcat
>
>and other containers as well, provided that newer log4j versions are
>backward compatible.
>
I don't understand what you mean here? If the server provides only Java2 classloading behavior, no matter what you bundle with your app, you are at the mercy of the server version. Backwards compatibility would certainly be key in keeping apps running, but the discussion was the webapp controlling its own version of Log4j, and that is not possible in this example, unless you are the server admin (or know the server admin well). This is why I said "....Under Tomat". Only server implementing child-first classloading behavior could allow you to bundle log4j.jar with the webapp and count on that version being used rather than the server version.
Jake
>
>>Jake
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
