Good to hear that this isn't that crazy of an idea. One more bit on part of my motivation to do this, JNDI DataSource configuration is always container specific and never friendly with command-line tools. Moving to a Spring configured pool would solve both of these.
As for places that really like to use container managed JNDI DataSources changing the Spring config to use those instead should be easy enough. It should also make switching pooling libraries much easier. -Eric PS: I agree that there is no good OSS pool out there even for basic object pooling. commons-pool really needs a re-visit using JDK5 read/write locks. Eric Dalquist wrote: > Anyone have any thoughts on this? > > If I don't hear any reasons to keep the JNDI configs as the default way > of doing things I'll be changing trunk to use commons-pool managed > DataSources in the portal's application context. > > -Eric > > Eric Dalquist wrote: > >> The issue of where to put those darn JDBC drivers has come up a few >> times in the last week or so on the -user list and has historically been >> a bit of an issue. >> >> I would like to propose no longer using a JNDI configured DataSource by >> default. With the consolidated Spring configuration I would like to >> create a dataSourceContext.xml as a place to configure JDBC DataSource >> objects. RDBMServices would be deprecated and re-worked to provide >> access to the DataSource objects from the Spring context. As work >> progresses to move more components into a Spring managed world they >> could bypass RDBMServices and simply have the DataSource injected directly. >> >> -Eric >> >>
smime.p7s
Description: S/MIME Cryptographic Signature
