At 10:19 AM 2/25/2005 -0700, you wrote:
>
>Gilbert -
>
>I'm not sure I completely understand your scenario. But does it boil 
>down to this:
>
>1) you have common jars and app-specific jars
>2) sometimes an app needs to overwrite a common jar, and sometimes not
>3) if an an app needs to overwrite a common jar, you'd put it in 
>WEB-INF/lib and you'd like both Tomcat and OpenEJB to load it instead of 
>what's in common/lib or $OPENEJB_HOME/lib
>
>Is that close enough?

Thank you for your kind attention. I agree with points 1 and 2. Sometimes
we can get point 3 to work, sometimes not. Ideally, I would like to put our
collection of common jars in an arbitary directory, something like
/usr/local/mysuite.

For certain web applications, I would like to modify a configuration file,
like WEB-INF/web.xml, so that both Tomcat 4 and OpenEJB load common jars
/in addition/ to what's in common/lib or $OPENEJB_HOME/lib. As an
administrator, I would like to resolve conflicts between common jars, if
possible, without maintaining multiple copies of each jar, without going
back to negotiate with a vendor.

Using WEB-INF/web.xml, can I modify the classpath for a web application?

If a class exists in both WEB-INF/lib and common/lib, which one is used?

If a class exists in both WEB-INF/lib and $OPENEJB_HOME/lib, which one is
used?

If a class exists in WEB-INF/lib, /usr/local/mysuite and common/lib, which
one would be used?

By creating a new instance of Tomcat, we can put our collection of common
jars in catalina.base/common/lib, instead of catalina.home/common/lib. I
believe (a) catalina.home typically equals catalina.base, and (b)
catalina.base exists primarily to support multiple instances of Tomcat.
Creating a new instance of Tomcat is not that well understood by our
customers. Typically, we surrender to installing Tomcat on a new machine.

When the final release of OpenEJB 1.0 is ready, I can help create an
official RPM for it. Actually, I can create an Ant script to build the RPM
for it.

Thanks again,

Reply via email to