on 2/1/01 1:43 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:
> 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).
What *exactly* makes it unsuitable? You ask for a Connection object and you
get one and it works with all of the known JDBC database drivers out there.
I also do not see anywhere on the Struts homepage anything stating that all
components within the Struts framework must implement the J2EE API's.
> 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.
Ok, lets have some fun here...I'm going to play a game where I state what I
hear you saying and you tell me if I'm right and correct me if I'm wrong.
:-)
So I hear you saying:
You do not want to work together because you think that Turbine developers
have antipathy for *ALL* J2EE API's even though we have competing products
within the same project and that Turbine came long before Struts and Turbine
has support for JSP (which is the *only* J2EE API that I have ever heard
anyone in Turbine land complain about).
Sigh, I should have held my -1 on the Struts project creation way back when
because obviously you are not going to hold up to what you stated that you
would. Specifically (yes, this email was granted permission to be made
public):
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 12:45:17 -0700
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: [PROPOSAL/VOTE] New Jakarta Subproject - "Struts"
[...]
"Once the pattern is clear, it will be lots easier to integrate the
final result into Turbine, rather than doing the integration over and over
again as the patterns get refined."
[...]
I read that as saying that at some point, you wanted to work with the
Turbine project and not duplicate effort over and over and over again.
That is clearly contrary to what you are saying now.
> 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
My god Craig, you are scaring me. Do you believe that software shouldn't
evolve? :-)
Case in point: The changes that Sam quoted with regards to Turbine breaking
Jetspeed in a single tinderbox build were mitigated by the fact that the
Jetspeed developers asked for those changes to happen in the first place.
That is a tiny little bit of very important context that Sam conveniently
left out. :-)
With regards to Cocoon, he also left out the fact that we DID in fact mark
those changed database pool API's as deprecated for a few months before
removing the deprecated code.
Lets bring up another case of changing API's midstream. How about discussing
the modifications that are going to happen to the Tomcat 4.x Valves in order
to bring them more in line with the Filters API. :-) Somehow I doubt that
you are going to keep those deprecated methods and code around. We could
even go back to the point that Catalina implemented early Servlet API
methods that were not finalized and were later changed. Were those methods
deprecated before being changed? Somehow I doubt it.
:-)
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
