You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Martin Cooper <ma...@apache.org> on 2004/09/02 07:28:42 UTC
[PROPOSAL] Struts 1.2.3 release
We need to get a follow-up 1.2.3 release out the door as soon as possible,
due to the problems that have been identified with the 1.2.2 GA release.
The ball is already in play for a 1.2.3 release, with a preliminary build
available, and a release tracking page up on the wiki:
http://wiki.apache.org/struts/StrutsRelease123
The proposed timeline for this release is as follows:
* CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). The
candidate build will be uploaded to cvs.a.o shortly thereafter, and
announced to dev@s.a.o and user@s.a.o for testing.
* Initiation of Quality vote: Tuesday, September 7th. Duration of the
vote will be the usual 72 hours.
The strange dates and times have to do with (a) this coming weekend being
a holiday weekend in the USA, and (b) my having prior arrangements for
said holiday weekend. ;-)
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 7 Sep 2004 08:46:26 -0500, Joe Germuska <jo...@germuska.com> wrote:
> At 6:07 AM -0400 9/7/04, Ted Husted wrote:
> >On Tue, 07 Sep 2004 04:11:42 +0100, Niall Pemberton wrote:
> >> I have also committed a patch for Bug 31060 with the reasoning that
> >> if we need to re-create the 1.2.3 release then we should also take
> >> the opportunity to fix this bug as well:
> >
> >If it were just a matter of patching the DTD's on the Struts
> >Example, then I'd say we could reroll the 1.2.3 release.
> >
> >But if we are making further code changes, then I believe we should
> >move onto 1.2.4.
> >
> >The only practical difference being whether we apply a 1_2_4 tag or not.
>
> I don't know if there's a protocol about this, but actually, I wasn't
> quite clear on why Martin was being tentative about describing the
> release he cut as "officially" 1.2.3. It seems like any time someone
> goes through the process of building a release and putting it up for
> review, the number should be incremented. In the new scheme, version
> numbers are supposed to be "cheap" and there should be no shame in
> "burning them up".
No build is an official *release* until we've voted on it. This was a
test *build* that was made available for people to test out so that
they could have an informed opinion on what they would be voting on.
The distinction is important - we don't build releases, we build
builds; then we vote on whether a particular build should become a
release.
In this case, I agree with Ted (and I believe you ;) that we should
roll the version number to 1.2.4. As you say, the version numbers are
cheap. As for there being no shame - sure. 1.2.3 was only a test
build, after all, and never released. ;-) That's why we have test
builds.
--
Martin Cooper
>
> I don't feel terribly strongly about this.
>
> Joe
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
> back; I'll know I'm in the wrong place."
> - Carlos Santana
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Ted Husted <hu...@apache.org>.
On Tue, 07 Sep 2004 08:46:26 -0500, Joe Germuska wrote:
>�I don't know if there's a protocol about this, but actually, I
>�wasn't quite clear on why Martin was being tentative about
>�describing the release he cut as "officially" 1.2.3.
The build was officially named "1.2.3", but, as Martin says, it wasn't an Apache Release.
When we tag and roll the build, we are essentially creating a named nightly build, and like the nightly build, it is "absolutely alpha".
To graduate a build from "absolutely alpha" to a "beta" or "general availability" release, we need to conduct a majority vote of the Struts PMC.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Joe Germuska <Jo...@Germuska.com>.
At 6:07 AM -0400 9/7/04, Ted Husted wrote:
>On Tue, 07 Sep 2004 04:11:42 +0100, Niall Pemberton wrote:
>> I have also committed a patch for Bug 31060 with the reasoning that
>> if we need to re-create the 1.2.3 release then we should also take
>> the opportunity to fix this bug as well:
>
>If it were just a matter of patching the DTD's on the Struts
>Example, then I'd say we could reroll the 1.2.3 release.
>
>But if we are making further code changes, then I believe we should
>move onto 1.2.4.
>
>The only practical difference being whether we apply a 1_2_4 tag or not.
I don't know if there's a protocol about this, but actually, I wasn't
quite clear on why Martin was being tentative about describing the
release he cut as "officially" 1.2.3. It seems like any time someone
goes through the process of building a release and putting it up for
review, the number should be incremented. In the new scheme, version
numbers are supposed to be "cheap" and there should be no shame in
"burning them up".
I don't feel terribly strongly about this.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Ted Husted <hu...@apache.org>.
On Tue, 07 Sep 2004 04:11:42 +0100, Niall Pemberton wrote:
> I have also committed a patch for Bug 31060 with the reasoning that
> if we need to re-create the 1.2.3 release then we should also take
> the opportunity to fix this bug as well:
If it were just a matter of patching the DTD's on the Struts Example, then I'd say we could reroll the 1.2.3 release.
But if we are making further code changes, then I believe we should move onto 1.2.4.
The only practical difference being whether we apply a 1_2_4 tag or not.
I'll be happy when we finally get past this stage, and artifacts like the Struts Mailreader Example can be released separately. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
As Vic has pointed out, an issue has come up on the struts-user list
concerning the struts-examples application - it doesn't run locally, without
a connection to the outside world.
Seems that when the struts-exercise-taglib.war was refactored into
struts-examples.war the DOCTYPE was changed from PUBLIC to SYSTEM for the
web.xml and struts-config.xml files. I have committed changes to correct
this and it seems to me that we need to include this fix in the Struts 1.2.3
release.
I have also committed a patch for Bug 31060 with the reasoning that if we
need to re-create the 1.2.3 release then we should also take the opportunity
to fix this bug as well:
http://issues.apache.org/bugzilla/show_bug.cgi?id=31060
The reason I'm keen for this to be included is that the getErrors() method
(which was added in Struts 1.2.1) returns an ActionErrors object - this will
create backward compatibility problems for users in the future if we change
it to an ActionMessages object. As its only the return type that needs
changing, we qwouldn't be able to simply deprecate and add a new version of
the method. Seems to me that as it was added in Struts 1.2.1 and therefore
isn't part of a GA release of Struts the best thing is to simply change the
method now (along with the new saveErrors() method also added in Struts
1.2.1).
Niall
----- Original Message -----
From: "Vic" <vi...@portalvu.com>
To: <de...@struts.apache.org>
Sent: Monday, September 06, 2004 9:25 PM
Subject: Re: [PROPOSAL] Struts 1.2.3 release
> please patch as per user thread: "Struts 1.2.2/1.2.3 struts-examples.war
> not working" w/ a solution in there.
>
> .V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Vic <vi...@portalvu.com>.
please patch as per user thread: "Struts 1.2.2/1.2.3 struts-examples.war
not working" w/ a solution in there.
.V
--
Please post on Rich Internet Applications User Interface (RiA/SoA)
<http://www.portalvu.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 05 Sep 2004 00:35:14 -0700, Michael McGrady
<mi...@michaelmcgrady.com> wrote:
> Martin Cooper wrote:
>
> >So much for being out of town for the long weekend. Thanks to my
> >neighbours, I woke up to a waterlogged house, and am currently sitting
> >amongst a fleet of industrial-grade dehumidifiers. This is not fun. My
> >neighbours, of course, are away for the long weekend, no doubt having
> >fun...
> >
> >Anyway, the point of this message is to let folks know that, since I'm
> >stuck here anyway, I've run the JUnit and Cactus tests on the Struts
> >1.2.3 build, on both JDK 1.3 and JDK 1.4, and all have succeeded. So I
> >think we're in good shape.
> >
> >--
> >Martin Cooper
> >
>
> Thanks, Martin. Sorry to hear about your misfortune. What happened to
> the house? Don't tell me they have a broken line that runs into your
> home or something? Lord! You know what they say? Good fences make
> good neighbors. I am not really in favor of it but this seems like a
> good day for that for you.
My neighbours left an irrigation sprinkler on full blast when they
went away for the long weekend. It completely saturated the ground,
kind of like raising the local water table, the result being that the
water came up through the concrete pad and into my house. (My house
happens to be a few inches downslope from their vegetable patch,
unfortunately.)
--
Martin Cooper
>
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Martin Cooper wrote:
>So much for being out of town for the long weekend. Thanks to my
>neighbours, I woke up to a waterlogged house, and am currently sitting
>amongst a fleet of industrial-grade dehumidifiers. This is not fun. My
>neighbours, of course, are away for the long weekend, no doubt having
>fun...
>
>Anyway, the point of this message is to let folks know that, since I'm
>stuck here anyway, I've run the JUnit and Cactus tests on the Struts
>1.2.3 build, on both JDK 1.3 and JDK 1.4, and all have succeeded. So I
>think we're in good shape.
>
>--
>Martin Cooper
>
Thanks, Martin. Sorry to hear about your misfortune. What happened to
the house? Don't tell me they have a broken line that runs into your
home or something? Lord! You know what they say? Good fences make
good neighbors. I am not really in favor of it but this seems like a
good day for that for you.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <mf...@gmail.com>.
So much for being out of town for the long weekend. Thanks to my
neighbours, I woke up to a waterlogged house, and am currently sitting
amongst a fleet of industrial-grade dehumidifiers. This is not fun. My
neighbours, of course, are away for the long weekend, no doubt having
fun...
Anyway, the point of this message is to let folks know that, since I'm
stuck here anyway, I've run the JUnit and Cactus tests on the Struts
1.2.3 build, on both JDK 1.3 and JDK 1.4, and all have succeeded. So I
think we're in good shape.
--
Martin Cooper
On Sat, 4 Sep 2004 07:13:25 -0700 (PDT), Martin Cooper
<ma...@apache.org> wrote:
> The Struts 1.2.3 build is up and announced, as proposed below. As you will
> see from the wiki, I have not run unit tests. Unbelievably, just as I
> started to do so last night, my power went out, and stayed out. (I hope
> this isn't the start of another California power crisis...) Since we
> needed to get this build out, I took the risk that everything is OK, and
> am hoping that one of the other developers will be able to verify this and
> update the wiki. I want to stress that this is not something I do lightly,
> but unfortunately (for Struts, but not for me ;), I'm going to be out of
> town over the long weekend and don't have time to follow up, and I do
> feel that it's urgent that we get a 1.2.2 replacement out there.
>
> --
> Martin Cooper
>
>
>
>
> On Wed, 1 Sep 2004, Martin Cooper wrote:
>
> > We need to get a follow-up 1.2.3 release out the door as soon as possible,
> > due to the problems that have been identified with the 1.2.2 GA release. The
> > ball is already in play for a 1.2.3 release, with a preliminary build
> > available, and a release tracking page up on the wiki:
> >
> > http://wiki.apache.org/struts/StrutsRelease123
> >
> > The proposed timeline for this release is as follows:
> >
> > * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). The
> > candidate build will be uploaded to cvs.a.o shortly thereafter, and
> > announced to dev@s.a.o and user@s.a.o for testing.
> >
> > * Initiation of Quality vote: Tuesday, September 7th. Duration of the
> > vote will be the usual 72 hours.
> >
> > The strange dates and times have to do with (a) this coming weekend being a
> > holiday weekend in the USA, and (b) my having prior arrangements for said
> > holiday weekend. ;-)
> >
> > --
> > Martin Cooper
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <ma...@apache.org>.
The Struts 1.2.3 build is up and announced, as proposed below. As you will
see from the wiki, I have not run unit tests. Unbelievably, just as I
started to do so last night, my power went out, and stayed out. (I hope
this isn't the start of another California power crisis...) Since we
needed to get this build out, I took the risk that everything is OK, and
am hoping that one of the other developers will be able to verify this and
update the wiki. I want to stress that this is not something I do lightly,
but unfortunately (for Struts, but not for me ;), I'm going to be out of
town over the long weekend and don't have time to follow up, and I do
feel that it's urgent that we get a 1.2.2 replacement out there.
--
Martin Cooper
On Wed, 1 Sep 2004, Martin Cooper wrote:
> We need to get a follow-up 1.2.3 release out the door as soon as possible,
> due to the problems that have been identified with the 1.2.2 GA release. The
> ball is already in play for a 1.2.3 release, with a preliminary build
> available, and a release tracking page up on the wiki:
>
> http://wiki.apache.org/struts/StrutsRelease123
>
> The proposed timeline for this release is as follows:
>
> * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). The
> candidate build will be uploaded to cvs.a.o shortly thereafter, and
> announced to dev@s.a.o and user@s.a.o for testing.
>
> * Initiation of Quality vote: Tuesday, September 7th. Duration of the
> vote will be the usual 72 hours.
>
> The strange dates and times have to do with (a) this coming weekend being a
> holiday weekend in the USA, and (b) my having prior arrangements for said
> holiday weekend. ;-)
>
> --
> Martin Cooper
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 2 Sep 2004 22:20:33 -0700, Martin Cooper <mf...@gmail.com> wrote:
> On Thu, 2 Sep 2004 21:49:17 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> > On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper <mf...@gmail.com> wrote:
> > > On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted <hu...@apache.org> wrote:
> > > > On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote:
> > > > > * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time).
> > > >
> > > > Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too.
> > >
> > > I'd been thinking that we'd create the branch, based on the tag, when
> > > we decide we need / want it.
> > >
> > > > Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x.
> > >
> > > Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree
> > > of revolution will happen in this next (2.3-based) version, as well as
> > > some logical evolution. I haven't yet seen any proposed advantages *to
> > > Struts future* listed for Servlets 2.4, and my own focus is on getting
> > > away from JSP dependencies in the core, so I'm not sure how much the
> > > 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0.
> > > But that's really another thread...
> > >
> >
> > I gathered that the conclusion for the "evolution" branch (which,
> > IMHO, should be called 1.3 if it's going to focus on things like the
> > chain version of RequestProcessor but remain fundamentally backwards
> > compatible).
>
> The conclusion was... I think you didn't quite finish the sentence. ;-)
>
> One example of a concrete set of changes that I want to make in a
> Servlets 2.3 compliant "next" version of Struts will involve the use
> of a filter for file uploads, as well as significant changes to the
> interfaces involved. These are interfaces that are exposed as hooks
> today, so this would certainly break backwards compatibility. That
> makes it questionable, in my mind, as to whether we should make such
> changes in a dot release.
>
> And then there's the question of changing the core Servlets dependency
> in a dot release. Some time ago, we decided that we couldn't do that
> in a dot release, and needed to wait for a major version hike. We're
> allowed to change our minds, of course, but I just wanted to remind
> folks of what we had agreed on a while ago. ;-)
>
> If calling a "next" release 1.3 means we get to upgrade the dependency
> to 2.3, but have to remain backwards compatible in all other respects,
> then I think that would be unnecessarily limiting, and would suggest
> that we call it 2.0 instead.
>
> Of course, it's conceivable that we have a 2.0 based on Servlets 2.3
> and a 3.0 based on Servlets 2.4 in development at the same time (a la
> Tomcat from a couple of years ago), but I think this would be
> unfortunate, especially if both groups were changing interfaces in
> different ways.
>
> > FWIW, here are some specific technical benefits (for the
> > framework architecture, for applications based on it, or both) if we
> > were to choose Servlet 2.4 over Servlet 2.3:
> >
> > * HttpServletRequest.setCharacterEncoding() allows applications to
> > resolve nearly all the ambiguities of parsing request parameters in
> > the right encoding (which is a smaller number of problems than it used
> > to be in 2.4 generally, because the rules have been tightened, and
> > because of the next feature).
> >
> > * You can define (in web.xml) your own mapping table from locale
> > to character encoding, rather than relying on the container's
> > undocumented (and likely non-portable) defaults.
> >
> > * Filters can be declared to run on RequestDispatcher.forward() calls
> > as well as on the original request. Without this, it's basically impossible
> > to write use-case-specific Filters in an MVC framework that uses
> > RD.forward() the way Struts does today.
> >
> > * ServletRequestListener fleshes out the lifecycle model, so you can do things
> > like adding some resource to the request attributes, and knowing that it will
> > get cleaned up (after the response has been rendered by the JSP page or
> > whatever) by your listener.
> >
> > * ServletRequestAttributeListener can listen to changes on your request
> > attributes, similar to how HttpSessionAttributeListener and
> > ServletContextAttributeListener work in 2.3.
> >
> > * On an HttpSessionBindingListener, the listener is invoked when you actually
> > expect it to be at session end (*before* the session is invalidated,
> > rather than after).
> >
> > * "Welcome Files" can now be servlets, so you can use "index.do" instead
> > of having an "index.jsp" that forwards to an action that does your setup.
> >
> > * Deployment descriptors (web.xml) that conform to the 2.4 schema can
> > have their elements listed in any order, instead of the pretty arbitrary
> > sequence required by 2.3.
>
> These are all nice things to have, and would no doubt help clean some
> things up somewhat and fix some issues in people's Struts apps. But
> what I was really trying to ask was: What new Struts features do
> people have in mind that would *require* the use of Servlets 2.4 to
> accomplish?
>
> > The benefits of JSP 2.0 over 1.2 are even more compelling, but have
> > been discussed before. My favorite three favorite features are EL
> > everywhere, tag files (a way to create "simple UI components" with
> > just JSP code), and the simple tag API.
> >
> > Counterbalancing all of this, of course, is the question of installed
> > base. And, of course, that is a question that has a different answer
> > at different times. If we want to work towards a GA quality 1.3
> > release in 3-6 months (possible if the set of changes is limited),
> > than staying with 2.3/1.2 makes a lot of sense. But if it takes us
> > the more typical 12-18 months, where do *you* think the world is going
> > to be by then?
>
> To be honest, I expect that some app server vendors will not be much
> further along than they are today. It is only recently, for example,
> that WebSphere has even supported JDK 1.4, and not *that* long since
> IBM and BEA introduced support for Servlets 2.3 / JSP1.2. However, I
> would be very happy to be wrong about that. ;-)
One other related point: I cannot make architectural decisions for my
products based on the hope that the container support will be there
before I'm done - something I would have no control of. That means
that, realistically, I would be unable to *start* development using a
Servlet 2.4-based version of Struts until the app servers were
available, at least as Beta versions. With a Servlets 2.3-based
version of Struts, I can start development as soon as I believe that
the necessary core interfaces are stable - and, of course, I have the
ability to help make that happen in the timeframe that I need.
--
Martin Cooper
>
> --
> Martin Cooper
>
>
>
>
> > NOTE: None of this is to suggest that maintenance activities on 1.2.x
> > should not continue. However, it should, IMHO, be focused on bug
> > fixes rather than feature enhancements, and should (of course) remain
> > based on Servlet 2.2 / JSP 1.1.
> >
> > > --
> > > Martin Cooper
> >
> > Craig
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 2 Sep 2004 21:49:17 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper <mf...@gmail.com> wrote:
> > On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted <hu...@apache.org> wrote:
> > > On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote:
> > > > * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time).
> > >
> > > Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too.
> >
> > I'd been thinking that we'd create the branch, based on the tag, when
> > we decide we need / want it.
> >
> > > Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x.
> >
> > Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree
> > of revolution will happen in this next (2.3-based) version, as well as
> > some logical evolution. I haven't yet seen any proposed advantages *to
> > Struts future* listed for Servlets 2.4, and my own focus is on getting
> > away from JSP dependencies in the core, so I'm not sure how much the
> > 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0.
> > But that's really another thread...
> >
>
> I gathered that the conclusion for the "evolution" branch (which,
> IMHO, should be called 1.3 if it's going to focus on things like the
> chain version of RequestProcessor but remain fundamentally backwards
> compatible).
The conclusion was... I think you didn't quite finish the sentence. ;-)
One example of a concrete set of changes that I want to make in a
Servlets 2.3 compliant "next" version of Struts will involve the use
of a filter for file uploads, as well as significant changes to the
interfaces involved. These are interfaces that are exposed as hooks
today, so this would certainly break backwards compatibility. That
makes it questionable, in my mind, as to whether we should make such
changes in a dot release.
And then there's the question of changing the core Servlets dependency
in a dot release. Some time ago, we decided that we couldn't do that
in a dot release, and needed to wait for a major version hike. We're
allowed to change our minds, of course, but I just wanted to remind
folks of what we had agreed on a while ago. ;-)
If calling a "next" release 1.3 means we get to upgrade the dependency
to 2.3, but have to remain backwards compatible in all other respects,
then I think that would be unnecessarily limiting, and would suggest
that we call it 2.0 instead.
Of course, it's conceivable that we have a 2.0 based on Servlets 2.3
and a 3.0 based on Servlets 2.4 in development at the same time (a la
Tomcat from a couple of years ago), but I think this would be
unfortunate, especially if both groups were changing interfaces in
different ways.
> FWIW, here are some specific technical benefits (for the
> framework architecture, for applications based on it, or both) if we
> were to choose Servlet 2.4 over Servlet 2.3:
>
> * HttpServletRequest.setCharacterEncoding() allows applications to
> resolve nearly all the ambiguities of parsing request parameters in
> the right encoding (which is a smaller number of problems than it used
> to be in 2.4 generally, because the rules have been tightened, and
> because of the next feature).
>
> * You can define (in web.xml) your own mapping table from locale
> to character encoding, rather than relying on the container's
> undocumented (and likely non-portable) defaults.
>
> * Filters can be declared to run on RequestDispatcher.forward() calls
> as well as on the original request. Without this, it's basically impossible
> to write use-case-specific Filters in an MVC framework that uses
> RD.forward() the way Struts does today.
>
> * ServletRequestListener fleshes out the lifecycle model, so you can do things
> like adding some resource to the request attributes, and knowing that it will
> get cleaned up (after the response has been rendered by the JSP page or
> whatever) by your listener.
>
> * ServletRequestAttributeListener can listen to changes on your request
> attributes, similar to how HttpSessionAttributeListener and
> ServletContextAttributeListener work in 2.3.
>
> * On an HttpSessionBindingListener, the listener is invoked when you actually
> expect it to be at session end (*before* the session is invalidated,
> rather than after).
>
> * "Welcome Files" can now be servlets, so you can use "index.do" instead
> of having an "index.jsp" that forwards to an action that does your setup.
>
> * Deployment descriptors (web.xml) that conform to the 2.4 schema can
> have their elements listed in any order, instead of the pretty arbitrary
> sequence required by 2.3.
These are all nice things to have, and would no doubt help clean some
things up somewhat and fix some issues in people's Struts apps. But
what I was really trying to ask was: What new Struts features do
people have in mind that would *require* the use of Servlets 2.4 to
accomplish?
> The benefits of JSP 2.0 over 1.2 are even more compelling, but have
> been discussed before. My favorite three favorite features are EL
> everywhere, tag files (a way to create "simple UI components" with
> just JSP code), and the simple tag API.
>
> Counterbalancing all of this, of course, is the question of installed
> base. And, of course, that is a question that has a different answer
> at different times. If we want to work towards a GA quality 1.3
> release in 3-6 months (possible if the set of changes is limited),
> than staying with 2.3/1.2 makes a lot of sense. But if it takes us
> the more typical 12-18 months, where do *you* think the world is going
> to be by then?
To be honest, I expect that some app server vendors will not be much
further along than they are today. It is only recently, for example,
that WebSphere has even supported JDK 1.4, and not *that* long since
IBM and BEA introduced support for Servlets 2.3 / JSP1.2. However, I
would be very happy to be wrong about that. ;-)
--
Martin Cooper
> NOTE: None of this is to suggest that maintenance activities on 1.2.x
> should not continue. However, it should, IMHO, be focused on bug
> fixes rather than feature enhancements, and should (of course) remain
> based on Servlet 2.2 / JSP 1.1.
>
> > --
> > Martin Cooper
>
> Craig
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper <mf...@gmail.com> wrote:
> On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted <hu...@apache.org> wrote:
> > On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote:
> > > * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time).
> >
> > Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too.
>
> I'd been thinking that we'd create the branch, based on the tag, when
> we decide we need / want it.
>
> > Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x.
>
> Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree
> of revolution will happen in this next (2.3-based) version, as well as
> some logical evolution. I haven't yet seen any proposed advantages *to
> Struts future* listed for Servlets 2.4, and my own focus is on getting
> away from JSP dependencies in the core, so I'm not sure how much the
> 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0.
> But that's really another thread...
>
I gathered that the conclusion for the "evolution" branch (which,
IMHO, should be called 1.3 if it's going to focus on things like the
chain version of RequestProcessor but remain fundamentally backwards
compatible). FWIW, here are some specific technical benefits (for the
framework architecture, for applications based on it, or both) if we
were to choose Servlet 2.4 over Servlet 2.3:
* HttpServletRequest.setCharacterEncoding() allows applications to
resolve nearly all the ambiguities of parsing request parameters in
the right encoding (which is a smaller number of problems than it used
to be in 2.4 generally, because the rules have been tightened, and
because of the next feature).
* You can define (in web.xml) your own mapping table from locale
to character encoding, rather than relying on the container's
undocumented (and likely non-portable) defaults.
* Filters can be declared to run on RequestDispatcher.forward() calls
as well as on the original request. Without this, it's basically impossible
to write use-case-specific Filters in an MVC framework that uses
RD.forward() the way Struts does today.
* ServletRequestListener fleshes out the lifecycle model, so you can do things
like adding some resource to the request attributes, and knowing that it will
get cleaned up (after the response has been rendered by the JSP page or
whatever) by your listener.
* ServletRequestAttributeListener can listen to changes on your request
attributes, similar to how HttpSessionAttributeListener and
ServletContextAttributeListener work in 2.3.
* On an HttpSessionBindingListener, the listener is invoked when you actually
expect it to be at session end (*before* the session is invalidated,
rather than after).
* "Welcome Files" can now be servlets, so you can use "index.do" instead
of having an "index.jsp" that forwards to an action that does your setup.
* Deployment descriptors (web.xml) that conform to the 2.4 schema can
have their elements listed in any order, instead of the pretty arbitrary
sequence required by 2.3.
The benefits of JSP 2.0 over 1.2 are even more compelling, but have
been discussed before. My favorite three favorite features are EL
everywhere, tag files (a way to create "simple UI components" with
just JSP code), and the simple tag API.
Counterbalancing all of this, of course, is the question of installed
base. And, of course, that is a question that has a different answer
at different times. If we want to work towards a GA quality 1.3
release in 3-6 months (possible if the set of changes is limited),
than staying with 2.3/1.2 makes a lot of sense. But if it takes us
the more typical 12-18 months, where do *you* think the world is going
to be by then?
NOTE: None of this is to suggest that maintenance activities on 1.2.x
should not continue. However, it should, IMHO, be focused on bug
fixes rather than feature enhancements, and should (of course) remain
based on Servlet 2.2 / JSP 1.1.
> --
> Martin Cooper
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Ted Husted <hu...@apache.org>.
On Thu, 02 Sep 2004 13:50:30 -0700, Martin Cooper wrote:
>�Do we want to call that 1.3.x or 2.0.x? I'm thinking that some
>�degree of revolution will happen in this next (2.3-based) version,
>�as well as some logical evolution. I haven't yet seen any proposed
>�advantages *to Struts future* listed for Servlets 2.4, and my own
>�focus is on getting away from JSP dependencies in the core, so I'm
>�not sure how much the 2.4/2.0 fans want to change that couldn't
>�happen in Struts 1.3/2.0. But that's really another thread...
I'd say 1.3.x.
Moving the minimum platform is worth rolling the minor version number, but there are not any API changes on the table.
When and if something revolutionary happens, we can always roll the major version number then.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted <hu...@apache.org> wrote:
> On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote:
> > * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time).
>
> Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too.
I'd been thinking that we'd create the branch, based on the tag, when
we decide we need / want it.
> Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x.
Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree
of revolution will happen in this next (2.3-based) version, as well as
some logical evolution. I haven't yet seen any proposed advantages *to
Struts future* listed for Servlets 2.4, and my own focus is on getting
away from JSP dependencies in the core, so I'm not sure how much the
2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0.
But that's really another thread...
--
Martin Cooper
>
> -T.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [PROPOSAL] Struts 1.2.3 release
Posted by Ted Husted <hu...@apache.org>.
On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote:
> * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time).
Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too.
Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org