tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Kirk" <>
Subject RE: JNDI DataSource GlobalResources problem
Date Thu, 28 Oct 2004 15:11:20 GMT

I have been in learning mode about Resource/Context config for the last few
weeks, mainly from the point of view of DBCP config.  I did find all the
alternatives confusing at first, but having read more and more docs, and
getting some help from the good people on this list, I'm starting to "get
it" now.  I've had DBCP working for several months, the confusing issue is
how best to config it.

IMHO, TC provides very good support for configuring Resources/Contexts, and
doesn't need to change (although there may be one or two documentation
tweaks that would help beginners, which I intend to submit soon).  Whether
you are a container administrator wanting to config global resources, or
per-webapp resources, or a webapp author wanting to config your own
resources, TC provides you with at least one way to do it.  And these are
all "bonus" features, in the sense that they are not mandated in the servlet

Again IMHO, if there is a problem in this area, it's that these features are
TC-specific, so if you use them in developing your webapp, you are making
your webapp less portable to other containers (as Yoav has pointed out).  An
improvement in portability can only really come if the servlet spec changes
to mandate how this stuff is configured.  So the spec is the area that needs
to be addressed next, rather than TC.

Until then, there are ways of doing pretty much what you want with TC
already in this area.  It might not be _exactly_ as you would ideally like,
but hey, it works if you really need it, and you can be bothered to use
what's already there.  And this list is always there to help you if you are
confused as to which option to choose.

.... all just IMHO :)

> -----Original Message-----
> From: Benson Margulies [] 
> Sent: Thursday 28 October 2004 02:28
> To: Tomcat Users List; Allen Holub
> Subject: RE: Re[2]: JNDI DataSource GlobalResources problem
> 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:

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

View raw message