views:

507

answers:

2

Hi,

I’m running a couple of servlet applications in Tomcat (5.5). All of the servlets use a common factory resource that is shared out using JNDI. At the moment, I can get everything working by including the factory resource as a GlobalNamingResource in the /conf/server.xml file, and then having each servlet’s META-INF/context.xml file include a ResourceLink to the resource. Snippets from the XML files are included below. NOTE: I’m not that familiar with tomcat, so I’m not saying that this is a good configuration!!!

However, I now want to be able install these servlets into multiple tomcat instances automatically using an RPM. The RPM will firstly copy the WARs to the webapps directory, and the jars for the factory into the common/lib directory (which is fine). But it will also need to make sure that the factory resource is included as a resource for all of the servlets.

What is the best way add the resource globally? I’m not too keen on writing a script that goes into the server.xml file and adds in the resource that way. Is there any way for me to add in multiple server.xml files so that I can write a new server-app.xml file and it will concatenate my settings to server.xml? Or, better still to add this JNDI resource to all the servlets without using server.xml at all?

p.s. Restarting the server will not be an issue, so I don’t mind if the changes don’t get picked up automatically.

Thanks

Snippet from server.xml

  <!-- Global JNDI resources -->
  <GlobalNamingResources>

  <Resource name="bean/MyFactory"
                auth="Container"
                type="com.somewhere.Connection"
                factory="com.somewhere.MyFactory"/> 
  </GlobalNamingResources> 

The entire servlet’s META-INF/context.xml file

<?xml version="1.0" encoding="UTF-8"?>
<Context>
    <ResourceLink global="bean/MyFactory"
                name="bean/MyFactory"
                type="com.somewhere.MyFactory"/>
  </Context>
A: 

This doesn't directly answer your question, but have you instead considered putting all your config inside your context.xml file, instead of in server.xml? This makes your web-app more fully self-contained, which sounds important to your deployment requirements.

I'd go as far to say it might be worth considering any refactoring necessary to ensure your apps can be fully self-contained if this can't be done at present.

Having worked on projects where I deployed /common/lib JARs and common resources, and been bitten by them in confusing and subtle ways (I eventually found out these were invariably my own fault btw, not blaming Tomcat here), I now favour a completely protective approach to my webapps: keep 'em completely independent.

But of course I don't fully know your circumstances, just some suggestions.

Brian
+1  A: 

Since Tomcat 4, the recommendation has been not to put any JNDI information in the server.xml file. Check Tomcat 5.5's documentation:

For Tomcat 5, unlike Tomcat 4.x, it is NOT recommended to place elements directly in the server.xml file. This is because it makes modifying the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.

I know you claim not to care about this, but trust me, your deployment team does, and the maintenance team will thank you later. Even if this means you end up thanking yourself.

If you need a JNDI setting to be shared among all webapps on a server, you should put it into the file $CATALINA_HOME/conf/context.xml. In all likelihood, there will be an existing context.xml already in that location, but you should be able to write a simple app to add your resource nodes via your favorite language and whatever DOM builder comes bundled with it. Or, if you want to stick with the command line, check out this article, which gives a few XML-processing shell scripts to help you out.

Good luck!

rtperson