Funny, I was thinking of mentioning that in my post below, but didn't because I hadn't checked that it would definitely work. But that's what I'm going to do from now on. Thanks Yoav, this looks like the "right" answer to me.
Don't know why I didn't think of it earlier really. I suppose it's because when you first try this, you google for something like "servlet connection pooling", and get to various DBCP how-to pages, and away you go down that path, and get tied up with context.xml vs server.xml, META-INF/ vs conf/, and WARs vs unpacked apps. etc etc. No more context.xml or <Context>s for me. Unless the spec changes.... > -----Original Message----- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Thursday 28 October 2004 16:21 > To: Tomcat Users List > Subject: RE: JNDI DataSource GlobalResources problem > > > > 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:[EMAIL PROTECTED] > >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:[EMAIL PROTECTED] > >> 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
