Jon Stevens wrote:
> 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.
>
In a J2EE app, the usual approach for acquiring resource instances from an
appropriate factory is to look up the factory instance in a container-provided JNDI
context. The resource factory then returns an instance of the appropriate class.
To ensure portability, the APIs for common resource factories (and therefore the
resources that you can acquire from those factories) are standardized:
* JDBC Connections - javax.sql.DataSource and
* JMS Connections - javax.jms.QueueConnectionFactory
or javax.jms.TopicConnectionFactory
* JavaMail connections - javax.mail.Session
* URL connections - java.net.URL
These requirements allow an application to be portable across application servers --
for example, to use whichever JDBC connection pool implementation is provided by
that container.
Coding an app to the Turbine connection pool's API is certainly feasible, and it
will run in this kind of environment -- but you will not be using the container's
built in facilities, which allow containers to implement things like distributed
transaction support, integrated authentication checking, and everything else that is
in the J2EE platform requirements.
>
> 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.
>
Turbine grows features in response to the needs of its users (and, of course, the
willingness of people to contribute effort to it). So does Struts.
A large and growing portion of the Struts community are building apps for deployment
in J2EE environments. Implementing features that are not aligned with the
corresponding APIs would be a disservice to them. NOTE: The issue isn't
"everything in Struts must be a J2EE API". Rather, it's "nothing in Struts should
violate J2EE API requirements."
>
> > 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).
>
Your comments about EJBs ("who needs them" "useless" etc.) in mailing lists, and in
your Turbine presentation at ApacheCon Europe, were pretty direct complaints :-).
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
