tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: JNDI DataSource GlobalResources problem
Date Thu, 28 Oct 2004 15:21:14 GMT

Hi,
Besides completely agreeing with Steve (so Benson, your time could
probably be better spent elsewhere, such as by putting on the <tech
writer> hat you mentioned earlier), I wanted to mention one other
alternative.

You *always* have the option of *not* using container-managed resources,
and managing them yourself.  I do this 99% of the time, as the
portability and management advantages overwhelmingly cover cons.  For
the DBCP case, you take the DBCP jar (and its two dependent jars), put
them in WEB-INF/lib, and write a couple of lines of code to configure
your pool(s).  Literally, that's all it takes, and now you've got your
one package with no need for a server-specific configuration file etc.

Yoav Shapira http://www.yoavshapira.com
 

>-----Original Message-----
>From: Steve Kirk [mailto:tomcat-user@web-startup.co.uk]
>Sent: Thursday, October 28, 2004 11:11 AM
>To: 'Tomcat Users List'
>Subject: RE: JNDI DataSource GlobalResources problem
>
>
>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
>spec.
>
>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 [mailto:bim2004@basistech.com]
>> 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: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message