On 4/16/07, Ken Miller 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
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.


To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 9 | next ›
Discussion Overview
groupuser @
postedApr 17, '07 at 2:12a
activeApr 20, '07 at 3:30p



site design / logo © 2017 Grokbase