tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <>
Subject RE: Re[2]: JNDI DataSource GlobalResources problem
Date Thu, 28 Oct 2004 01:27:52 GMT
As I read the discussion, I don't think that anyone claimed that only
WAR's are interesting or important.

Yoav, in one posting, explained that the servlet spec is written from a
point of view that only requires support for applications in unexploded
WAR files. That is not the same thing as stating that only WARs are
interesting. It is just a way of illuminating some requirements for
behaviors of the container.

In another posting, Yoav expressed a generic distaste for Global
resources -- all other things being equal.

Of late, there's been a rash of people wanting to use global resources,
either for database pooling or for JNI reasons. The commercial
containers have various kinds of adminstrative UI arrangements for this
purpose. No one that I know of supports a self-contained package that
bundles a web app with administrative/resource/global configuration, but
I haven't made a comprehensive survey. Semi-seriously, I wonder about a
GRaR -- a Global Resource aRchive, as a way to package up a set of
global classlibs and the config to deploy them into JNDI.

I've experimented with writing a simple Java command-line application to
set up an application with global resources. It assumes that the app
will deploy outside the webapps dir. It edits server.xml and creates the
context file to point to the tree. It wasn't very complex. 

I have some ideas as to why them-that-vote are not enthused about
META-INF/server.xml as a generic feature of a web application tree. If
there is also context file in Catalina/HOST/xxx.xml, which one wins? How
loudly will someone yell when a WAR file has unexpected implications
because it has a server.xml? As things are, META-INF/server.xml is a
feature of a particular management path, not a feature of webapps. 

Mostly, I end up feeling that this is more of a documentation problem.
Developer after developer reads the servlet spec, which is quite murky
in this area since it defers important stuff to the container. Then,
they either never read the relevant tomcat howtos, or fail to understand
them. As a recent contributor to them I get some of the blame for the
later turn of events.

In big letters, someplace, people need to see 'if your webapp needs
resources from the container, and especially if you need container-wide
shared resources, you are not in Kansas any longer'.

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

View raw message