> >The one included is not the same as what is in RC1, though, 
> >correct? 
> I'm not sure what Ted changed but you may be correct that 
> it's not exactly 
> the same.  You can still use DBCP, Struts just won't 
> distribute it any more.

If I move away from DBCP and try to use just the features included with RC2
(for now), it seems like there have been a lot of changes.

GenericDataSource now handles all the pooling and stuff itself, instead of
relying on BasicDataSource, which is fine.
But, it also relies on GenericConnection, of which there are two versions -
one for JDK1.3, one for JDK1.4. And the one for JDK1.3 will _not_ compile
JDK1.4. (according to the docs). That's a bummer, because if I release an
app with the 1.3 version packaged in, and the server is upgraded to 1.4, I'm
going to assume that things will break?

I'm not looking for a long-term fix, just a short-term switch to possibly
avoid the problems that DBCP might have been causing for me. I'm just
finding it a challenge to figure out which short-term fix to use.

> You're not tying your app to the container because you configure the 
> DataSource implementation entirely in JNDI (my preference) or 
> struts-config.xml.

In struts-config.xml, if I define my type= to be a container-specific class,
though, then it's no longer portable. Unless I'm completely misunderstanding
what you mean, which is likely :)

I'm going to explore "better" ways to handle db connections in the future,
but as I said above, I'm just looking for a patch to address current
problems with DBCP, so I want to keep defining my db conns in
struts-config.xml, and I want to rely only on the classes packaged with
struts (if possible). I'll experiment and see how it works!

Matt Kruse

Reply via email to