tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Server-wide
Date Thu, 09 May 2002 00:15:56 GMT

On Wed, 8 May 2002, Matthew Stone wrote:

> Date: Wed, 8 May 2002 12:14:36 -0400
> From: Matthew Stone <>
> Reply-To: Tomcat Users List <>
> To:
> Subject: Server-wide
> Greetings.
> Someone in the turbine-users list suggested I post this message here:
> Could someone please explain to me the correct way to configure Tomcat to
> use several Turbine web-app's that are shared between each other.
> For example, I have web-app's A, B & C.
> A - contains velocity stuff and a Turbine service I created
> B - contains another Turbine service I created
> C - contains legacy jsp pages and acts as front end to A & B
> I know it looks like I've answer my own questions below but please read it
> all the way through if you are looking to help me because I think my answers
> will help shed light on my confusion.
> Here are my specific questions:
> 1. Where should the Turbine related JAR's be stored in the Tomcat directory
> structure?  In \tomcat\lib or each respective \webapp\web-inf\lib directory?
> I believe it should be the former for 2 reasons.  First it's cleaner than
> having the JAR's duplicated.  Second and most important because the runtime
> will create multiple instances of the TurbineServices singleton thus not
> allowing web-app C to locate the services in A & B.

The only valid answer is "it depends".  Four examples of why this is

What happens when one of the shared packages is rev'd, and application A
works with the new version but application B still requires the old
version?  Then, you are better off having the classes in each webapp.

What happens when the shared package needs to be able to instantiate
objects from classes that are in your webapp?  If it's not programmed
specifically to deal with this scenario (i.e. it uses the thread context
class loader), you'll get a bunch of class not found exceptions.

What happens if your shared package creates static variables and correct
behavior depends on those variables being unique per webapp?  Then, having
the package inside WEB-INF is the only possible solution.

What happens if your shared package creates static variables and you
really do want to share them across multiple webapps?  Then, having the
package in a shared place is the only possible solution.

> 2. Should the services I've created in web-app's A & B be moved out of the
> web-app into a shared location in the Tomcat directory?  Again I believe the
> answer is yes because web-app C needs to be able to resolve the class names
> for the services in A & B.

Your shared services have the same potential problem that any other shared
code does -- it won't be able to create instances of classes that are
located inside the webapp (unless it uses the context class loader).  The
usual result is that you have to move all the classes your shared services
depend on into the shared location, plus all the classes those classes
depend on, and so on.

However, the more you share things between webapps, the more complex your
environment becomes -- and the more risk you have in being locked into
Tomcat (the servlet spec does not require that a container provide access
to shared classes at all, although most of them do).

> 3. Finally the question I don't have the answer for.  If my answers are
> correct for questions 1 & 2, how do I configure Tomcat to only use 1
> file.  For example, could I drop it into the
> tomcat\conf directory and have it init all my services from there?  If so,
> what XML file do I change and what should I put in it?  Right now web-app's
> A & B each have their own unique TR.Prop files in their respective
> \web-inf\conf directories and all of the settings are the same.  Then at the
> end of the TR.prop file I use to specify specific
> variables for service A and I also do the same thing for web-app B changing
> the accordingly.  The bottom line is there a more
> elegant way to do this?

That sounds like a question for the Turbine users mailing list.

> Please let me know if you need more information.
> Thanks in advance!
> Regards,
> Matt

Craig McClanahan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message