"Craig R. McClanahan" wrote: > I disagree with what I think you are saying. > > Struts follows the J2EE convention that data sources are configured on a > per-webapp basis. The details of exactly what database is being accessed > (and the database username/password being used) can be easily made > external to the webapp itself by using the standard data source support of > your app server. (Tomcat 4 supports this for non-EJB apps in a compatible > manner.)
I'm just running cold on Struts being in the connection-pool business. When we added this, there wasn't another place to put it or a ready alternative. Neither of these statements are true anymore. The recent release of Poolman work very well with Struts, and can be access from the business layer. I'm sure there are now others as well. And, as you know, the connection pool breu-ha-ha is why we founded the Commons. I would like to see it moved, or deprecated and have the docs suggest other likely products. I'd move it myself, but I'm not particularly interested in supporting it afterwards. I do agree that anything we suggest should follow J2EE conventions, support datasources directly, and also work well with the Jakarta Taglibs dbTags. >From a pure technical perspective, since there is not a portable way to expose our connection pool outside the ServletContext, I feel that it sends the wrong message to developers, just as having ActionForm as an interface sent the wrong message. Of late, it has become a support burden, and I don't see committers stepping up to the plate to answer the difficulties people report when using the Generic Pool in a production environment. (Probably because none of us are.) Struts is now considered a production tool, and anything we distribute should meet that standarfd. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
