struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Struts Connection Pool Maturity - Ted - you out there?
Date Wed, 24 Apr 2002 22:45:24 GMT

On Wed, 24 Apr 2002, Sandra Cann wrote:

> Date: Wed, 24 Apr 2002 17:21:09 -0400
> From: Sandra Cann <>
> Reply-To: Struts Users Mailing List <>
> To: Struts Users Mailing List <>
> Subject: RE: Struts Connection Pool Maturity - Ted - you out there?
> Interesting.... This doesn't compute for me. Should we Expresso NOT use
> Struts or any other Apache project because it is outside of our quality
> control?  No of course not, because we know the collaborative comunity
> process is such that if we had an issue it would be addressed either by us
> contributing the fix or the core developers.  The point of the matter is
> there is no mechanism within Apache to use third party open source tools.

Each Apache subproject lets the committers on that subproject make their
own decisions on things like that.  It's one of the nicer things about the
Apache culture -- no pointy-haired-boss types mandating global policies on
technical issues :-).

Some Apache project teams take a much more liberal view of integrating
third party stuff (Cocoon and Turbine come to mind).  Others don't.  Their

> This is disheartening! By appearances Apache is interested in only code
> contributed to its Intellectual Property and will not support third party
> projects.
> What is more dishearterning to me is this: Considering that in March 2002
> Apache was requesting an open and fair licensing scheme from Sun for
> developing Java standards.... isn't this hypocritical? Basically Apache is
> asking Sun to use third party "open source" projects in Java when Apache
> itself won't integrate other third party open source projects!!!

That's not at all what happened ... what Apache negotiated for (and won)
was the legal right to implement Java specifications -- both for ourselves
and for any other open source organization that wants to -- and then prove
(by passing the TCKs) that the implementations are spec-compliant.
Formerly, this was not legally possible.

It doesn't have anything to do with whether Sun (or anyone else) should or
should not incorporate Apache code in Sun's products (which it does, by
the way -- JAXP is now based on Xerces and Xalan, while Tomcat is used in
both the J2EE RI and JWSDP).  That is a separate business decision, made
by the project teams for those products, on the usual build-or-buy
decision approach - the same sort of decision process that you undoubtedly
used in deciding to incorporate Struts support into Espresso.

> I would like to propose that Apache should consider its own words and apply
> them to its own organization and also support third party open source
> projects that are worthy and are offered under an Apache Style or BSD
> license.

Apache's representative on the JCP executive committee has spent two years
of pain (and a useful amount of Apache Software Foundation money on
lawyer's fees)  building consensus and arguing for ***your*** right to
implement Java specs legally if you want to.  We didn't just do it for
ourselves.  But that has exactly zero to do with where the code shipped
with Apache packages itself originated, or whether somebody else includes
Apache code or not.

> Expresso has more than twice the community listserv size of Struts and has
> earned its recognition as a solid framework.
> Respectfully and disappointed

Why are you disappointed?  I responded with a (clearly marked) *personal*
opinion -- one of ten or so voices that count (the other committers).  If
others are willing to support an imported third party module, then that is
fine.  But I feel a personal moral obligation to Struts users that
anything included in the official Struts distribution needs to be
supported by the Struts developer community, no matter where the original
code came from.  As long as that's done, third party code is fine.

> --
> Sandra Cann


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message