Mailing-List: contact general-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A7A134E.4E01C000@eng.sun.com>
Date: Thu, 01 Feb 2001 17:54:22 -0800
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: general@jakarta.apache.org
Subject: Re: What is Struts? (was: Re: What is Avalon?)
References: <B69F40C6.20E8B%jon@latchkey.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

NOTE:  I accidentally pressed "Send" rather than "Save" while editing this message.
The completed response below includes additional comments.

Jon Stevens wrote:

> on 2/1/01 1:43 PM, "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
> 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 :-).

Yes, Turbine came first.  And it implements what it includes quite well.  No
question.  But part of being first is deciding what to do when the rest of the world
tries to catch up, and standardizes APIs for some of the features you implement.
This is a strategic decision that the Turbine community needs to make for itself.

The effort cost to me of involving myself in that community, to help you think about
if you want to conform to J2EE API patterns (and contributing code if you did --
otherwise it wouldn't scratch any of my itches) would far exceed the effort cost of
implementing a connection pool that does something similar to what Turbine provides,
but does so in a manner compatible with the standard that came along later.

>
> 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: <39341A4C.E72AEFD1@eng.sun.com>
> Date: Tue, 30 May 2000 12:45:17 -0700
> From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
> To: <pmc@jakarta.apache.org>
> 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.
>

In my idealism of last year, I assumed that I would have enough available awake
hours to do so.  I simply don't have the cycles to engage in yet another high volume
/ high quality email list, or the emotional energy to put up with the anti-JSP
sentiment that would undoubtedly come my way.

What I will do for Turbine, however, is work to give you the best possible servlet
container on which to run it.

>
> > 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? :-)
>

Software should evolve.  It should get better.  But, if you want software to be used
on large scale projects with lifetimes measured in years (not months), you need to
be serious about backwards compatibility on APIs.

>
> 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. :-)
>

I'm not familiar with the details of Sam's specific issues -- what I was echoing is
agreement with the gist of the points he was making.  In fact, my personal
experience is that it goes beyond APIs -- how many times have you had to go back and
change your build scripts to keep up with the rate of change in Ant?

>
> 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.
>

Changing the fundamental APIs was not my idea.  But, the suggested approach was
better -- and if you're going to do it, before an x.0 release is exactly the time to
make those changes.  Or, would you rather see the fundamental interfaces change on
every dot release (Tomcat 3.0 -> 3.1 -> 3.2 -> 3.3 comes to mind)?

For a counter-example, you might look at how Struts bends over backwards to support
the APIs of the 0.5 milestone release, even in the face of pretty substantial
improvements.  The number of developers, and the amount of already existing code,
impacted by these changes was *substantially* higher than the number of people who
have written Valves to date -- so it was worth the investment in effort.

Had the Valves change actually been made in 4.1 instead of 4.0, you would certainly
see deprecations and backwards compatibility support.

>
> :-)
>
> -jon
>

Craig


NOTE:  The servlet and JSP APIs are *still* not finalized -- the specs implemented
by the current code are "Proposed Final Draft".  Any changes that happen in the
final drafts must, of course, be reflected in Tomcat for it to remain true to its
mission of faithfully implementing those specs.