struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arron Bates" <struts-...@keyboardmonkey.com>
Subject Re: Yes, it's another VOTE: RELEASE STRUTS 1.1 WITH DBCP NIGHTLY BUILD
Date Thu, 08 May 2003 11:05:17 GMT
> David Graham wrote:
>  > It's important to remember that the only reason we have commons-pool
>  > as a dependency is because DBCP uses it.  Once we jettison DBCP from
>  > our code we can also drop pool.
>  >
>  > I am -1 on this proposal because RC2 should also include a final
>  > version of FileUpload.  I would be +1 on an RC2 proposal that included
>  > final versions of all commons jars.  Why not just use the previous
>  > release of DBCP?
>  >
>  > I've done a lot of work on our commons dependencies and Struts bugs
>  > recently.  Sadly, I don't think I can help much more on DBCP as the
>  > time requirement to get it released appears to be high and the
>  > original authors are busy elsewhere.  I'm really hoping we can release
>  > Struts 1.1 with the previous release of DBCP and drop the dependency
>  > for 1.2 but we'll see what the rest of the team thinks...
> 
> The core issue is that we need a default DataSource connection pool for 
> the datasource element.
> 
> In Struts 1.0, we had our own GenericDataSource. GDS works, but only so 
> well. In Struts 1.1, being good citizens, we've been trying to migrate 
> to DBCP. For backward-compatibility, DBCP is actually being called from 
> inside a wrapper that makes it look like the GDS.
> 
> I've been using GDS in an intranet application, and it seems to work 
> well enough for that (so long as you use the pingQuery clause). I've 
> tried to switch over to DBCP earlier this year, but ran into issues (may 
> be those bugs they are trying to close), and rolled back to a 
> tried-and-true container-based pool. So, based on my own experience, I'm 
> not sure that I could vote +1 on using a prior version of DBCP.
> 
> The best option may be to rollback to the GDS. This is, after all, a 
> point release, and the GDS is at least a known factor. Without looking, 
> I imagine we should be able to just drop the wrapper and use it directly 
> again. If nothing else turns up, I'll give this a try later today. If it 
> works, I'll post a diff along with a vote to make this product change.

Couldn't GDS turn into an interface which extends the DataSource interface,
get a factory and a concrete class behind it which provides the open and close
methods to a pool implementation (dbcp, GDS or otherwise)?... or is this
simply naive thinking?...

Config's looking for a DataSource impl. Can we change this to look for a GDS
impl first, and then default to the DataSource?... If it's a datasource, we
can pass it to a generic datasource wrapper and let the wrapper worry about
downgrading the functionality rather than where Struts uses it itself.

Then others can write simple GDS wrapper implementations for other obscure
pools simply by using our interface. Popular ones could be donated and put
into util sub package. Naturally people could just tell the commity where to
get them from elsewhere.

Sorry if that was verbage no-one needed to hear.  :)


Arron.



> I'm surprised that there is not more interest in getting DBCP released. 
> It's being used by a couple of other products now, including Tomcat and 
> Hibernate. So, you'd think more people would be willing to chip-in. =:(
> 
> -Ted.
> 
> David Graham wrote:
> > It's important to remember that the only reason we have commons-pool as 
> > a dependency is because DBCP uses it.  Once we jettison DBCP from our 
> > code we can also drop pool.
> > 
> > I am -1 on this proposal because RC2 should also include a final version 
> > of FileUpload.  I would be +1 on an RC2 proposal that included final 
> > versions of all commons jars.  Why not just use the previous release of 
> > DBCP?
> > 
> > I've done a lot of work on our commons dependencies and Struts bugs 
> > recently.  Sadly, I don't think I can help much more on DBCP as the time 
> > requirement to get it released appears to be high and the original 
> > authors are busy elsewhere.  I'm really hoping we can release Struts 1.1 
> > with the previous release of DBCP and drop the dependency for 1.2 but 
> > we'll see what the rest of the team thinks...
> > 
> > David
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org





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


Mime
View raw message