You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/02/02 01:35:18 UTC
What is Struts? (was: Re: What is Avalon?)
on 2/1/01 1:43 PM, "Craig R. McClanahan" <Cr...@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.
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: <39...@eng.sun.com>
Date: Tue, 30 May 2000 12:45:17 -0700
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <pm...@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.
> 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
Re: What is Struts? (was: Re: What is Avalon?)
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/1/01 5:42 PM, "Peter Donald" <do...@apache.org> wrote:
> Actually you follow a lot of the patterns of J2EE aswell - you just do it
> differently. Their services directory via JNDI is equivelent to your
> singleton setup, you use log4j/other for logging while they will use that
> godforsaken sucky logging JSR, you use X they use Y ... ;)
To be more accurate, Turbine provides a way to build ANY logging system into
the backend. That is one of the beauties of Turbine...it is very good at
being the container for any number of technologies.
:-)
> In the long run it would be kewl to allow dual access so that J2EE devs
> could use turbine in a similar manner to most other newer web/enterprise
> apps.
Actually, I have a couple great emails from someone at Nokia that uses
Turbine (see below)...obviously we are doing *something* right. :-) Please
note that both of his issues (in Logging and Services) have already been
resolved.
> Of course a lot of the J2EE design decisions suck and you would have
> to live with them if you went that path ;)
No shit. I'm really tired of this constant pressure to use J2EE when
obviously so many things about it just plain suck...primarily JSP.
I had a great conversation today with Jason Hunter about his upcoming second
edition O'Reilly book on Servlets and how he spent a bunch of time doing
non-biased comparisons between different technologies in order to let people
come up with their own opinions on what they think of the different
implementation approaches instead of the constant pressure to simply use
what Sun's tells them to use. Funny, that sounds like a M$ thing to do.
It is amazing to me how anyone would want to use some of these technologies.
His comparison between Struts and Tea and WebMacro was a real eye opener as
to the fact that even though Struts is JSP done right, it still doesn't even
begin to hide the overall warts in JSP. I can't wait till that book is
published so that people can see these differences in plain as day examples.
Needless to say, I think that I'm going to start doing my own comparisons
and placing them up for people to comment. It is time that people wake up
and realize that the way that Sun dictates for people to do things isn't
necessarily the right way to do things.
-jon
> ----------
> From: Ext-Ilkka.Priha@nokia.com
> Reply-To: "Turbine" <tu...@list.working-dogs.com>
> Date: Tue, 23 Jan 2001 15:23:09 +0200
> To: turbine@list.working-dogs.com
> Subject: JMX integration issues
>
> Hi
>
> We have started an attemt to integrate Turbine to our JMX (Java Management
> eXtensions from Sun) based network agent framework. The framework includes
> its own server and doesn't support servlets directly but a somewaht lighter
> concept that we call request processors. It was a straightforward task to
> convert the Turbine servlet into a processor and get the system running.
> However, two static classes caused some problems.
>
> 1) It would be useful if the static Log supported customizable instances
> that could redirect log messages to whatever logging system is used in the
> integrating environment.
>
> 2) TurbineServices implements nicely the ServiceBroker interface and
> provides protected constructors. However, the instance member is private and
> the getInstance method returns a reference to the class instance, not to the
> implemented interface, although the getService method of the interface is
> almost the only one needed outside the class. A possibility to extend and
> customize the TurbineServices instance would make it possible to support
> other service construction methods than Class.forName and additional broker
> mechanisms.
>
> Other components of Turbine, like assembler factories, seemed to be
> extremely well configurable and customizable. The need to modify some of the
> base classes arise from our JMX based object management and broker system
> that we'd like to use for Turbine based objects also. One benefit of a
> separate broker system is a possibility to use different instances of the
> same Turbine module class depending on the context, e.g. pages maintaining
> state of a group of users and supporting several simultaneous groups.
>
> Ilkka
> --
> Ilkka Priha
> Nokia Networks
> http://www.nokia.com/networks
> mail: ext-ilkka.priha@nokia.com
> ----------
> From: Ext-Ilkka.Priha@nokia.com
> Reply-To: "Turbine" <tu...@list.working-dogs.com>
> Date: Wed, 24 Jan 2001 09:39:04 +0200
> To: turbine@list.working-dogs.com
> Subject: RE: JMX integration issues
>
> Rafal, Thanks for your comment. I'm waiting for LogService...
>
> Here is some background information about JMX.
>
> JMX has evolved from a hardware related need to be able to manage thousands
> of different devices using different protocols in a telecommunications
> network. JMX solves the problem with Java so well that the same framework
> can be used for managing software components as well. The idea is to have a
> centralized object registry server, through which clients can ask for
> service objects they need. The registry fully hides the implementation of
> the objects and even their physical location. The registry provides a kind
> of handle, an ObjectName instance, with which to access the properties and
> methods of the implementing object. The handle makes it possible to change
> the implementation during run-time without disturbing any of the clients.
> The objects can be any Java objects either implementing an interface based
> on a certain naming rule or providing a dynamic description object about
> their exposed functionality. So it's easy to convert existing objects to
> managed ones. Sun considers JMX as a pre-implementation of Jini. The idea is
> the same, but JMX supports more clearly centralized management in one
> machine while Jini is a fully decentralized approach managing services
> dynamically around the net.
>
> The JMX framework contains also a web-based management view, based on
> reflection, to the registry and all of the registered objects. This view
> makes it possible to monitor the run-time status of the system, change the
> configuration and even load new objects into the system.
>
> We're using JMX both for its original purpose, for managing devices with
> SNMP, and for managing the components of the device management server
> itself, like connectors, containers, sessions, processors, socket factories,
> thread factories and pools, loggers, Turbine services and modules, etc.
> We've applied many design principles from the Apache Avalon project, but
> used JMX in implementation as it provides most of the required functionality
> readily available. We've added some glue between our system and JMX to be
> able to access registered objects also directly in order to achieve fast
> performance in request processing. The extension listens to registration
> events updating the direct references automatically when needed so that we
> don't lose any of the original dynamics of the framework. Combining JMX with
> IBM's BML (Bean Markup Language) makes configuration and management of
> complicated client/server systems easier than any other approach I know
> about.
>
> http://java.sun.com/products/JavaManagement/index.html
>
> http://www.alphaworks.ibm.com/tech/bml
>
> -- Ilkka
> --
> Nokia Networks
> http://www.nokia.com/networks
> mail: ext-ilkka.priha@nokia.com
Re: What is Struts? (was: Re: What is Avalon?)
Posted by Peter Donald <do...@apache.org>.
At 05:33 1/2/01 -0800, Jon Stevens wrote:
>With regards to that directly, EJB's are also just one single technology
>within J2EE. In fact, Turbine tries very hard to follow a core J2EE
>technology that I believe strongly in...Servlets.
Actually you follow a lot of the patterns of J2EE aswell - you just do it
differently. Their services directory via JNDI is equivelent to your
singleton setup, you use log4j/other for logging while they will use that
godforsaken sucky logging JSR, you use X they use Y ... ;)
In the long run it would be kewl to allow dual access so that J2EE devs
could use turbine in a similar manner to most other newer web/enterprise
apps. Of course a lot of the J2EE design decisions suck and you would have
to live with them if you went that path ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: What is Struts? (was: Re: What is Avalon?)
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/1/01 5:22 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> 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.
The other feasibility would be to simply make Turbine's connection pool
implement that API. Previously someone had suggested doing this on the
Turbine list and I rejected it at the time because the User didn't give a
good reason (actually, they gave no reason at all).
In the case above, you give a good reason and I would be for it. But, it
doesn't matter...cause you never asked and never gave a reason. You just
simply went out and did it on your own without even trying to work
together...oh well...more duplicated code in Jakarta projects and more
confusion for our users...
It is funny, I'm arguing for less confusion for our users and you are
arguing for more confusion! I don't get it. :-(
> 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."
Funny, it doesn't say that on the homepage either.
> Your comments about EJBs ("who needs them" "useless" etc.) in mailing lists,
> and in
> your Turbine presentation at ApacheCon Europe, were pretty direct complaints
> :-).
My comments about EJB's are clearly:
They are only useful in a small percentage of applications. I say the same
thing about XML as well. I'm tired of people trying to fit every single
technology into every other technology without a scientific reason for *why*
it should be done.
With regards to that directly, EJB's are also just one single technology
within J2EE. In fact, Turbine tries very hard to follow a core J2EE
technology that I believe strongly in...Servlets.
-jon
Re: What is Struts? (was: Re: What is Avalon?)
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:
> on 2/1/01 1:43 PM, "Craig R. McClanahan" <Cr...@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 :-).
>
> 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: <39...@eng.sun.com>
> Date: Tue, 30 May 2000 12:45:17 -0700
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <pm...@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.
>
> > 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
Re: What is Struts? (was: Re: What is Avalon?)
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/1/01 5:54 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> 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.
I think that the decision is clear. :-)
> 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.
I don't agree that it would far exceed the effort cost.
> 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.
But you have enough time to re-write source code that was already written?
You have enough time to maintain yet another re-write of something that
already exists?
Your argument is silly to me because you are arguing that it code re-use is
a bad thing and we all know that isn't true.
> What I will do for Turbine, however, is work to give you the best possible
> servlet container on which to run it.
That's good to hear.
> 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.
That is exactly why I like a license like the BSD/ASF license. It allows you
to take a snapshot at any point in time and develop on it and never have to
worry about giving anything back.
That said, in the case of webapps, Servlets and Java, they are not mature
enough technologies to be able to able to count on a stable product with
API's that never change for years...anyone believing that is kidding
themselves.
> 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.
His overall points were good, but the examples were incorrect. :-)
> 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?
You know what? I'm really ok with updating my build scripts. It isn't that
big of a deal to replace <copyfile> with <copy>.
What happened to believing that software evolves? :-)
> 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)?
I was giving an example...
> 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.
Yep.
> Had the Valves change actually been made in 4.1 instead of 4.0, you would
> certainly see deprecations and backwards compatibility support.
Even still deprecations don't entirely solve the problem.
> 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.
NOTE: The Turbine and Avalon and Ant and Struts and and and and API's are
*still* not finalized -- the specs implemented by the current code are
"Standing on the heads of the developers". Any changes that happen in the
final drafts must, of course, be reflected in any applications for it to
remain true to its mission of faithfully implementing those specs.
:-)
-jon
Re: What is Struts? (was: Re: What is Avalon?)
Posted by Pier Fumagalli <pi...@betaversion.org>.
Jon Stevens <jo...@latchkey.com> wrote:
>
> FYI, I just *mostly* implemented the J2EE extensions for Turbine's
> Connection pool (the classes now at least implement the interfaces). It took
> me all of about 30 minutes.
>
> Have fun.
Thank you :) :) :)
Pier
--
Pier Fumagalli <ma...@betaversion.org>
Re: What is Struts? (was: Re: What is Avalon?)
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/1/01 5:54 PM, "Craig R. McClanahan" <Cr...@eng.sun.com>
wrote:
> * 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.
FYI, I just *mostly* implemented the J2EE extensions for Turbine's
Connection pool (the classes now at least implement the interfaces). It took
me all of about 30 minutes.
Have fun.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> | <http://java.apache.org/turbine/>
Re: What is Struts? (was: Re: What is Avalon?)
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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" <Cr...@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: <39...@eng.sun.com>
> Date: Tue, 30 May 2000 12:45:17 -0700
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <pm...@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.