I'd have stronger opinions if I was using an environment other then
Tomcat. However, in the Tomcat environment I don't see that it matters
much either way. In higher end app-server environments, it's probably
appropriate to let that server control the pools.
Even so, you can configure spring to use JNDI datasources on a per
installation environment if you need to. So I see no harm in converting
if you feel strongly.
Another thing to look at for a few minutes though, might be the recent
flurry in the Sakai community trying to convert from Commons Connection
Pooling to C3PO, which they did in response to a bug they hit in commons
pooling.
---- Cris J H
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
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
