On 4/16/07, Ken Miller <[EMAIL PROTECTED]> wrote:
Can someone point me (or at least give me a clue) where a potential problem may exist? I've configured my server to have a shared set of Commons and Struts jars (something I did before reading the above paragraph), and it appears to work, but I'd like to investigate a few situations which may cause problems to better understand the possible pitfalls.
There are at least two potential scenarios to watch out for. First, consider a case where you have a library commons-foo that your webapp depends on. Now, assume this library has a static variable "bar" defined in one of its classes. The challenge you have different semantics depending on where commons-foo.jar is located. * If commons-foo.jar is within /WEB-INF/lib, the static variable is global only to that particular web application. If two different webapps use this library, their uses of the static variable do not conflict. * If commons-foo.jar is stored in a shared classloader provided by your container (for example, in the shared/lib or common/lib directory for Tomcat) the global is shared *across* webapps, and any changes from webapp A can adversely impact webapp B. Second, consider what happens if library commons-foo needs to dynamically instantiate an instance of an application-provided class. The naive way for a library to do this is: String className = ...; // Calculate the name of the class you want Class clazz = Class.forName(className); Again, there are two different semantics (assuming the class to be loaded is part of your webapp, not part of the shared hierarchy): * If commons-foo.jar is within /WEB-INF/lib, the classloader can see your application class, and load it with no problems. * If commons-foo.jar is stored in a shared classloader provided by your container, you'll get a ClassNotFoundException. That happens because Class.forName() and friends start from the classloader that loaded the calling class itself (i.e. the commons-foo class doing this work) ... but your application class is not visible because you can only look *up* a classloader hierarchy, not down. The libraries that Struts itself depends on have likely shaken out most of the bugs like this since I wrote those warnings several years ago :-). But the only way to figure out if an arbitrary library will work in a shared environment is to exhaustively test and/or audit the code for statics and dynamic object creation. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
