Jon Stevens wrote:
>
> Shame on Struts for not using Turbine's Connection pool. That makes me very
> upset because this was something that Craig promised would not happen (that
> there wouldn't be much major duplication in Struts as in Turbine).
The connection pool in Turbine does not implement the
javax.sql.DataSource API
(from the JDBC 2.0 standard extensions package), which makes it
unsuitable for use
in a J2EE environment (a very common deployment scenario for Struts
based
applications).
Now, should I go try to lobby the Turbine developers to add this feature
(either
directly, or by wrapping)? Probably ... but I'm not going to go fight
that battle. Given the clear
antipathy that many Turbine developers have for the J2EE APIs, it is
*substantially* less effort to do separately what Struts requires,
versus lobby
/ cajole / argue / become a Turbine committer in order for the shared
module to
meet *my* needs.
The issues that Sam raises (lack of attention to backwards compatibility
of
interfaces, plus arbitrary changes in current development with no
consideration of
the fact that other people are depending on interface stability) have
bitten me
every single time I've gotten involved in a "shared utilities" sort of
environment. IMHO there will not be any quality sharing of supposedly
"reusable"
code until:
* People start designing code that is designed to be reused -- we
all have natural biases towards the original use for which we
scratched
that itch in the first place, and tend to create either explicit or
implcit
dependencies on the remainder of the original project.
* We find developers (for the "shared code" module) that are committed
to keeping the shared code stable, and to resolving the inevitable
disputes (I need StringUtils to do something this way; someone else
needs it to work that way).
* The shared code base is around long enough to regain the confidence
of people like me that they can depend on it -- and not have to go
back
and retrofit every time someone else decides to tweak a shared class
in a manner that is not backwards compatible.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
