You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Matthias Wessendorf <ma...@matthias-wessendorf.de> on 2004/11/18 13:48:39 UTC
Shale vs. Struts-Chain
Hi all,
I read the docs on subversion about Shale.
Well, a very interessting point.
However, I asked myself how it is related
to Struts/Commons - Chain. (The Proposal aka Jericho)
Has Struts Shale no relationship to (Struts/Commons)-Chain?
Seams that Chain is only for Struts 1.2 ?
or 1.3, which is based on Servlet2.2
And Shale, that will be on top of Servlet2.4,
will use Filter for CoR, isn't it?
Last but not least, the IoC (or dependency injection)
from Spring or Hivemind will be *included* into Struts / Shale?
Thanks for helping to clear my picture ;-)
Greetings,
Matthias
--
Matthias Weßendorf
Aechterhoek 18
DE-48282 Emsdetten
Germany
URL: http://www.wessendorf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Ted Husted <hu...@apache.org>.
At first, we were listing the ones that were going to held over to 1.3.x and leaving out the JavaServer Faces ones (that don't apply to the core).
I just finished adding the others, so that the tallies match (13 each as of now). There are four remaining that I'll try to resolve in the morning, which have my userid in the status column.
-Ted.
On Fri, 19 Nov 2004 20:24:01 -0800, Martin Cooper wrote:
>�I have to admit I'm a bit puzzled about what's on the wiki page
>�versus what comes up when I run my standard query against Bugzilla.
>�There are six bugs listed on the wiki page, but there appear to be
>�15 open issues in Bugzilla. Here's the list of bug numbers that
>�show up in Bugzilla but are not listed on the wiki page:
>
>�23127 - Page attribute of img and image tags doesn't use
>�pagePattern setting 31642 - <bean:include>�always include Session
>�id (if any) even for external Urls (href attribute)
>�32014 - HttpServletRequestWrapper in struts-faces broken for
>�servlet 2.4 32165 - FacesRequestProcessor bug when using prefix
>�mapped Struts servlet &�extension mapped Faces servlet 32265 - add
>�a warning to reset FormFile
>�32283 - Two slashes created by TagUtils.getActionMappingURL for
>�webapps in root context 32294 - html:text tag is not closed properly
>�32309 - Nonsense error messages from html:select/ options tags.
>�32310 - html:select/ options tags undocumented
>
>�Of these, 32014 and 32165 are struts-faces bugs, which I assume
>�we're not worrying about for 1.2.6. Should I simply be adding the
>�remainder to the wiki page, so that we're tracking them all there,
>�or is there a reason that they (at least the ones created before
>�today ;) are not already there?
>
>>�I would be in favor of immediately branching at 1.2.6,
>>�regardless, so we can start on 1.3.x. If there are any straggling
>>�issues with the 1.2.x build, I'd be happy to cross-commit between
>>�the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long
>>�enough, and it's time to "move on to bigger and better things".
>>
>
>�+1 to branching at 1.2.6. Assuming there are no objections, I'll
>�create a 1.2.x branch at the same time as I do the 1.2.6 label.
>
>�--
>�Martin Cooper
>
>
>>�We did tag and roll 1.2.5, it just didn't go anyplace, which is
>>�going to happen now and again.
>>
>>�-Ted.
>>
>>
>>�On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
>>
>>>>�Seams that Chain is only for Struts 1.2 ?
>>>>�or 1.3, which is based on Servlet2.2
>>>>
>>>�I believe that we reached consensus that it would be ok to move
>>>�Struts 1.3 to depend on Servlet 2.3. �Work on Struts 1.3 is
>>>�blocked on the release of a GA 1.2.x Struts so as to minimize
>>>�any need to apply patches across both branches.
>>>
>>>�Looking at http://wiki.apache.org/struts/StrutsRelease126, is
>>>�it true that we are just waiting for commons-validator 1.1.4 to
>>>�be marked "GA"? �The other bugs all seem to be marked for 1.3
>>>�except one which is underspecified.
>>>
>>>�Should we somehow annotate this page:
>>>�http://wiki.apache.org/struts/StrutsRelease125 to indicate that
>>>�there isn't going to be a 1.2.5 release? �Or should we have a
>>>�vote on it even though 1.2.6 is brewing?
>>>
>>>�Joe
>>>
>>�------------------------------------------------------------------
>>�--- 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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 1 Jun 2004 19:52:51 -0400, Ted Husted <hu...@apache.org> wrote:
> If everything else is resolved, I don't think we need to wait on Validator 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like a "showstopper" issue to me, and we can finish implementing the feature in the 1.3.x series.
>
> I'm trying to resolve the issues not listed as "outstanding" on the release plan, which should put us in a position to roll 1.2.6.
>
I have to admit I'm a bit puzzled about what's on the wiki page versus
what comes up when I run my standard query against Bugzilla. There are
six bugs listed on the wiki page, but there appear to be 15 open
issues in Bugzilla. Here's the list of bug numbers that show up in
Bugzilla but are not listed on the wiki page:
23127 - Page attribute of img and image tags doesn't use pagePattern setting
31642 - <bean:include> always include Session id (if any) even for
external Urls (href attribute)
32014 - HttpServletRequestWrapper in struts-faces broken for servlet 2.4
32165 - FacesRequestProcessor bug when using prefix mapped Struts
servlet & extension mapped Faces servlet
32265 - add a warning to reset FormFile
32283 - Two slashes created by TagUtils.getActionMappingURL for
webapps in root context
32294 - html:text tag is not closed properly
32309 - Nonsense error messages from html:select/ options tags.
32310 - html:select/ options tags undocumented
Of these, 32014 and 32165 are struts-faces bugs, which I assume we're
not worrying about for 1.2.6. Should I simply be adding the remainder
to the wiki page, so that we're tracking them all there, or is there a
reason that they (at least the ones created before today ;) are not
already there?
> I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to "move on to bigger and better things".
>
+1 to branching at 1.2.6. Assuming there are no objections, I'll
create a 1.2.x branch at the same time as I do the 1.2.6 label.
--
Martin Cooper
> We did tag and roll 1.2.5, it just didn't go anyplace, which is going to happen now and again.
>
> -Ted.
>
>
>
> On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
> >> Seams that Chain is only for Struts 1.2 ?
> >> or 1.3, which is based on Servlet2.2
> >>
> > I believe that we reached consensus that it would be ok to move
> > Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked
> > on the release of a GA 1.2.x Struts so as to minimize any need to
> > apply patches across both branches.
> >
> > Looking at http://wiki.apache.org/struts/StrutsRelease126, is it
> > true that we are just waiting for commons-validator 1.1.4 to be
> > marked "GA"? The other bugs all seem to be marked for 1.3 except
> > one which is underspecified.
> >
> > Should we somehow annotate this page:
> > http://wiki.apache.org/struts/StrutsRelease125 to indicate that
> > there isn't going to be a 1.2.5 release? Or should we have a vote
> > on it even though 1.2.6 is brewing?
> >
> > Joe
>
> ---------------------------------------------------------------------
> 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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Don Brown <mr...@twdata.org>.
+1 and I'll assist in knocking the remaining bugs down or anything else
necessary.
Don
> If everything else is resolved, I don't think we need to wait on Validator
> 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like
> a "showstopper" issue to me, and we can finish implementing the feature in
> the 1.3.x series.
>
> I'm trying to resolve the issues not listed as "outstanding" on the
> release plan, which should put us in a position to roll 1.2.6.
>
> I would be in favor of immediately branching at 1.2.6, regardless, so we
> can start on 1.3.x. If there are any straggling issues with the 1.2.x
> build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches.
> We've let 1.2.x block 1.3.x long enough, and it's time to "move on to
> bigger and better things".
>
> We did tag and roll 1.2.5, it just didn't go anyplace, which is going to
> happen now and again.
>
> -Ted.
>
> On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
>>> Seams that Chain is only for Struts 1.2 ?
>>> or 1.3, which is based on Servlet2.2
>>>
>> I believe that we reached consensus that it would be ok to move
>> Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked
>> on the release of a GA 1.2.x Struts so as to minimize any need to
>> apply patches across both branches.
>>
>> Looking at http://wiki.apache.org/struts/StrutsRelease126, is it
>> true that we are just waiting for commons-validator 1.1.4 to be
>> marked "GA"? The other bugs all seem to be marked for 1.3 except
>> one which is underspecified.
>>
>> Should we somehow annotate this page:
>> http://wiki.apache.org/struts/StrutsRelease125 to indicate that
>> there isn't going to be a 1.2.5 release? Or should we have a vote
>> on it even though 1.2.6 is brewing?
>>
>> Joe
>
>
>
>
> ---------------------------------------------------------------------
> 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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 1 Jun 2004 19:52:51 -0400, Ted Husted <hu...@apache.org> wrote:
> [snip]
> I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to "move on to bigger and better things".
>
+1
>
> -Ted.
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
If there has been no negative feedback on Commons Validator 1.1.4 by Monday
(2004-11-22) I was planning to call for a Vote to release it as "GA" quality
then.
I don't think we should vote on 1.2.5 since 1.2.6 is coming soon.
Niall
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
Sent: Thursday, November 18, 2004 2:21 PM
> I believe that we reached consensus that it would be ok to move
> Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked
> on the release of a GA 1.2.x Struts so as to minimize any need to
> apply patches across both branches.
>
> Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true
> that we are just waiting for commons-validator 1.1.4 to be marked
> "GA"? The other bugs all seem to be marked for 1.3 except one which
> is underspecified.
>
> Should we somehow annotate this page:
> http://wiki.apache.org/struts/StrutsRelease125 to indicate that there
> isn't going to be a 1.2.5 release? Or should we have a vote on it
> even though 1.2.6 is brewing?
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true
> that we are just waiting for commons-validator 1.1.4 to be marked
> "GA"?
read in commons-dev that 1.1.4 is now alpha
and available for Testing
-Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Vic <vi...@friendvu.com>.
Niall Pemberton wrote:
to include this in the last 1.2 release.
>
It does not have to be last 1.2, still could have 1.27 :-).
(and maybeeeeeee 1.3 should be called 1.4, just in case, it is a big
change).
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 20 Nov 2004 12:03:48 -0500, Ted Husted <hu...@apache.org> wrote:
> On Sat, 20 Nov 2004 07:56:02 -0800, Martin Cooper wrote:
> > Excellent! I will roll it today.
>
> The one thing might be a quick update of the release notes to catch us up. It should only be a couple of items. (I'd do it myself, but I'm juggling other responsibilities today.)
>
Yep, I just finished doing that, and will check in shortly.
--
Martin Cooper
> > BTW, I saw that you checked in a fix for #31642, but it still shows
> > as open in Bugzilla.
>
> Thanks, done.
>
> -Ted.
>
> ---------------------------------------------------------------------
>
>
> 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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Ted Husted <hu...@apache.org>.
On Sat, 20 Nov 2004 07:56:02 -0800, Martin Cooper wrote:
>�Excellent! I will roll it today.
The one thing might be a quick update of the release notes to catch us up. It should only be a couple of items. (I'd do it myself, but I'm juggling other responsibilities today.)
>�BTW, I saw that you checked in a fix for #31642, but it still shows
>�as open in Bugzilla.
Thanks, done.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 20 Nov 2004 10:46:10 -0500, Ted Husted <hu...@apache.org> wrote:
> I just realized my clock was off yesterday, so my posts might appear out of order. (Forward into the past!) Sorry for the inconvenience.
>
> Anyway, it looks to me like 1.2.6 is ready to roll, if someone wants to do the deed.
>
Excellent! I will roll it today.
BTW, I saw that you checked in a fix for #31642, but it still shows as
open in Bugzilla.
--
Martin Cooper
> -Ted.
>
>
>
> On Wed, 02 Jun 2004 09:14:12 -0400, Ted Husted wrote:
> > As mentioned, we can always tag and roll additional releases from
> > the 1.2.x branch. It's just a question of how much we want to
> > cross-commit between 1.3.x and 1.2.x.
> >
> > Right now, I'd say cross-committing this patch is the lesser of the
> > two evils.
> >
> > When validator 1.1.4 goes GA, I'd personally commit to rolling
> > 1.2.7, especially if we also get a patch for #23127 too.
> >
> > -Ted.
> >
> >
> > On Sat, 20 Nov 2004 11:54:35 +0000, Niall Pemberton wrote:
> >
> >> The issue is that Validator was missed out when message bundles
> >> was implemented in Struts - I'd prefer we wait for Validator
> >> 1.1.4 and fix #18169 and #21760 and that hole will then be
> >> plugged in the 1.2.x series.
> >>
> >> If we were carrying on in the 1.2.x series, then releasing 1.2.6
> >> and leaving them till next time would be fine by me - but since
> >> we're moving on to a 1.3 branch IMO it would be a good idea to
> >> include this in the last 1.2 release.
> >>
> >> Theres been no -ve feedback from anyone on Validator 1.1.4 so
> >> hopefully it will be voted GA in the next couple of days - can we
> >> really not delay a week for the 1.2.6 version and include this
> >> stuff?
> >>
> >> Niall
> >>
> >> ----- Original Message -----
> >> From: "Ted Husted" <hu...@apache.org>
> >> To: "Struts Developers List" <de...@struts.apache.org> Sent:
> >> Tuesday, June 01, 2004 11:52 PM
> >> Subject: Re: Release planning (was Re: Shale vs. Struts-Chain)
> >>
> >>
> >> If everything else is resolved, I don't think we need to wait on
> >> Validator 1.1.4. If it's ready when we are, fine. If not, #18169
> >> does not seem like a "showstopper" issue to me, and we can finish
> >> implementing the feature in the 1.3.x series.
> >>
> >> I'm trying to resolve the issues not listed as "outstanding" on
> >> the release plan, which should put us in a position to roll
> >> 1.2.6.
> >>
> >> I would be in favor of immediately branching at 1.2.6,
> >> regardless, so we can start on 1.3.x. If there are any
> >> straggling issues with the 1.2.x build, I'd be happy to cross-
> >> commit between the 1.2.x and 1.3.x branches. We've let 1.2.x
> >> block 1.3.x long enough, and it's time to "move on to bigger and
> >> better things".
> >>
> >> We did tag and roll 1.2.5, it just didn't go anyplace, which is
> >> going to happen now and again.
> >>
> >> -Ted.
> >>
> >> On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
> >>
> >>>> Seams that Chain is only for Struts 1.2 ?
> >>>> or 1.3, which is based on Servlet2.2
> >>>>
> >>> I believe that we reached consensus that it would be ok to move
> >>> Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is
> >>> blocked on the release of a GA 1.2.x Struts so as to minimize
> >>> any need to apply patches across both branches.
> >>>
> >>> Looking at http://wiki.apache.org/struts/StrutsRelease126, is
> >>> it true that we are just waiting for commons-validator 1.1.4
> >>> to be marked "GA"? The other bugs all seem to be marked for
> >>> 1.3 except one which is underspecified.
> >>>
> >>> Should we somehow annotate this page:
> >>> http://wiki.apache.org/struts/StrutsRelease125 to indicate that
> >>> there isn't going to be a 1.2.5 release? Or should we have a
> >>> vote on it even though 1.2.6 is brewing?
> >>>
> >>> Joe
> >>>
> >>
> >> ------------------------------------------------------------------
> >> -- - 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
>
>
> ---------------------------------------------------------------------
>
>
> 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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Ted Husted <hu...@apache.org>.
I just realized my clock was off yesterday, so my posts might appear out of order. (Forward into the past!) Sorry for the inconvenience.
Anyway, it looks to me like 1.2.6 is ready to roll, if someone wants to do the deed.
-Ted.
On Wed, 02 Jun 2004 09:14:12 -0400, Ted Husted wrote:
> As mentioned, we can always tag and roll additional releases from
> the 1.2.x branch. It's just a question of how much we want to
> cross-commit between 1.3.x and 1.2.x.
>
> Right now, I'd say cross-committing this patch is the lesser of the
> two evils.
>
> When validator 1.1.4 goes GA, I'd personally commit to rolling
> 1.2.7, especially if we also get a patch for #23127 too.
>
> -Ted.
>
>
> On Sat, 20 Nov 2004 11:54:35 +0000, Niall Pemberton wrote:
>
>> The issue is that Validator was missed out when message bundles
>> was implemented in Struts - I'd prefer we wait for Validator
>> 1.1.4 and fix #18169 and #21760 and that hole will then be
>> plugged in the 1.2.x series.
>>
>> If we were carrying on in the 1.2.x series, then releasing 1.2.6
>> and leaving them till next time would be fine by me - but since
>> we're moving on to a 1.3 branch IMO it would be a good idea to
>> include this in the last 1.2 release.
>>
>> Theres been no -ve feedback from anyone on Validator 1.1.4 so
>> hopefully it will be voted GA in the next couple of days - can we
>> really not delay a week for the 1.2.6 version and include this
>> stuff?
>>
>> Niall
>>
>> ----- Original Message -----
>> From: "Ted Husted" <hu...@apache.org>
>> To: "Struts Developers List" <de...@struts.apache.org> Sent:
>> Tuesday, June 01, 2004 11:52 PM
>> Subject: Re: Release planning (was Re: Shale vs. Struts-Chain)
>>
>>
>> If everything else is resolved, I don't think we need to wait on
>> Validator 1.1.4. If it's ready when we are, fine. If not, #18169
>> does not seem like a "showstopper" issue to me, and we can finish
>> implementing the feature in the 1.3.x series.
>>
>> I'm trying to resolve the issues not listed as "outstanding" on
>> the release plan, which should put us in a position to roll
>> 1.2.6.
>>
>> I would be in favor of immediately branching at 1.2.6,
>> regardless, so we can start on 1.3.x. If there are any
>> straggling issues with the 1.2.x build, I'd be happy to cross-
>> commit between the 1.2.x and 1.3.x branches. We've let 1.2.x
>> block 1.3.x long enough, and it's time to "move on to bigger and
>> better things".
>>
>> We did tag and roll 1.2.5, it just didn't go anyplace, which is
>> going to happen now and again.
>>
>> -Ted.
>>
>> On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
>>
>>>> Seams that Chain is only for Struts 1.2 ?
>>>> or 1.3, which is based on Servlet2.2
>>>>
>>> I believe that we reached consensus that it would be ok to move
>>> Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is
>>> blocked on the release of a GA 1.2.x Struts so as to minimize
>>> any need to apply patches across both branches.
>>>
>>> Looking at http://wiki.apache.org/struts/StrutsRelease126, is
>>> it true that we are just waiting for commons-validator 1.1.4
>>> to be marked "GA"? The other bugs all seem to be marked for
>>> 1.3 except one which is underspecified.
>>>
>>> Should we somehow annotate this page:
>>> http://wiki.apache.org/struts/StrutsRelease125 to indicate that
>>> there isn't going to be a 1.2.5 release? Or should we have a
>>> vote on it even though 1.2.6 is brewing?
>>>
>>> Joe
>>>
>>
>> ------------------------------------------------------------------
>> -- - 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Ted Husted <hu...@apache.org>.
As mentioned, we can always tag and roll additional releases from the 1.2.x branch. It's just a question of how much we want to cross-commit between 1.3.x and 1.2.x.
Right now, I'd say cross-committing this patch is the lesser of the two evils.
When validator 1.1.4 goes GA, I'd personally commit to rolling 1.2.7, especially if we also get a patch for #23127 too.
-Ted.
On Sat, 20 Nov 2004 11:54:35 +0000, Niall Pemberton wrote:
> The issue is that Validator was missed out when message bundles was
> implemented in Struts - I'd prefer we wait for Validator 1.1.4 and
> fix #18169 and #21760 and that hole will then be plugged in the
> 1.2.x series.
>
> If we were carrying on in the 1.2.x series, then releasing 1.2.6
> and leaving them till next time would be fine by me - but since
> we're moving on to a 1.3 branch IMO it would be a good idea to
> include this in the last 1.2 release.
>
> Theres been no -ve feedback from anyone on Validator 1.1.4 so
> hopefully it will be voted GA in the next couple of days - can we
> really not delay a week for the 1.2.6 version and include this
> stuff?
>
> Niall
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Tuesday, June 01, 2004 11:52 PM
> Subject: Re: Release planning (was Re: Shale vs. Struts-Chain)
>
>
> If everything else is resolved, I don't think we need to wait on
> Validator 1.1.4. If it's ready when we are, fine. If not, #18169
> does not seem like a "showstopper" issue to me, and we can finish
> implementing the feature in the 1.3.x series.
>
> I'm trying to resolve the issues not listed as "outstanding" on the
> release plan, which should put us in a position to roll 1.2.6.
>
> I would be in favor of immediately branching at 1.2.6, regardless,
> so we can start on 1.3.x. If there are any straggling issues with
> the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and
> 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's
> time to "move on to bigger and better things".
>
> We did tag and roll 1.2.5, it just didn't go anyplace, which is
> going to happen now and again.
>
> -Ted.
>
> On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
>>> Seams that Chain is only for Struts 1.2 ?
>>> or 1.3, which is based on Servlet2.2
>>>
>> I believe that we reached consensus that it would be ok to move
>> Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is
>> blocked on the release of a GA 1.2.x Struts so as to minimize any
>> need to apply patches across both branches.
>>
>> Looking at http://wiki.apache.org/struts/StrutsRelease126, is it
>> true that we are just waiting for commons-validator 1.1.4 to be
>> marked "GA"? The other bugs all seem to be marked for 1.3 except
>> one which is underspecified.
>>
>> Should we somehow annotate this page:
>> http://wiki.apache.org/struts/StrutsRelease125 to indicate that
>> there isn't going to be a 1.2.5 release? Or should we have a vote
>> on it even though 1.2.6 is brewing?
>>
>> Joe
>
>
> --------------------------------------------------------------------
> - 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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
The issue is that Validator was missed out when message bundles was
implemented in Struts - I'd prefer we wait for Validator 1.1.4 and fix
#18169 and #21760 and that hole will then be plugged in the 1.2.x series.
If we were carrying on in the 1.2.x series, then releasing 1.2.6 and leaving
them till next time would be fine by me - but since we're moving on to a 1.3
branch IMO it would be a good idea to include this in the last 1.2 release.
Theres been no -ve feedback from anyone on Validator 1.1.4 so hopefully it
will be voted GA in the next couple of days - can we really not delay a week
for the 1.2.6 version and include this stuff?
Niall
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, June 01, 2004 11:52 PM
Subject: Re: Release planning (was Re: Shale vs. Struts-Chain)
If everything else is resolved, I don't think we need to wait on Validator
1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like a
"showstopper" issue to me, and we can finish implementing the feature in the
1.3.x series.
I'm trying to resolve the issues not listed as "outstanding" on the release
plan, which should put us in a position to roll 1.2.6.
I would be in favor of immediately branching at 1.2.6, regardless, so we can
start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd
be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let
1.2.x block 1.3.x long enough, and it's time to "move on to bigger and
better things".
We did tag and roll 1.2.5, it just didn't go anyplace, which is going to
happen now and again.
-Ted.
On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
>> Seams that Chain is only for Struts 1.2 ?
>> or 1.3, which is based on Servlet2.2
>>
> I believe that we reached consensus that it would be ok to move
> Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked
> on the release of a GA 1.2.x Struts so as to minimize any need to
> apply patches across both branches.
>
> Looking at http://wiki.apache.org/struts/StrutsRelease126, is it
> true that we are just waiting for commons-validator 1.1.4 to be
> marked "GA"? The other bugs all seem to be marked for 1.3 except
> one which is underspecified.
>
> Should we somehow annotate this page:
> http://wiki.apache.org/struts/StrutsRelease125 to indicate that
> there isn't going to be a 1.2.5 release? Or should we have a vote
> on it even though 1.2.6 is brewing?
>
> Joe
---------------------------------------------------------------------
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: Release planning (was Re: Shale vs. Struts-Chain)
Posted by Ted Husted <hu...@apache.org>.
If everything else is resolved, I don't think we need to wait on Validator 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like a "showstopper" issue to me, and we can finish implementing the feature in the 1.3.x series.
I'm trying to resolve the issues not listed as "outstanding" on the release plan, which should put us in a position to roll 1.2.6.
I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to "move on to bigger and better things".
We did tag and roll 1.2.5, it just didn't go anyplace, which is going to happen now and again.
-Ted.
On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote:
>>�Seams that Chain is only for Struts 1.2 ?
>>�or 1.3, which is based on Servlet2.2
>>
>�I believe that we reached consensus that it would be ok to move
>�Struts 1.3 to depend on Servlet 2.3. �Work on Struts 1.3 is blocked
>�on the release of a GA 1.2.x Struts so as to minimize any need to
>�apply patches across both branches.
>
>�Looking at http://wiki.apache.org/struts/StrutsRelease126, is it
>�true that we are just waiting for commons-validator 1.1.4 to be
>�marked "GA"? �The other bugs all seem to be marked for 1.3 except
>�one which is underspecified.
>
>�Should we somehow annotate this page:
>�http://wiki.apache.org/struts/StrutsRelease125 to indicate that
>�there isn't going to be a 1.2.5 release? �Or should we have a vote
>�on it even though 1.2.6 is brewing?
>
>�Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Release planning (was Re: Shale vs. Struts-Chain)
Posted by Joe Germuska <Jo...@Germuska.com>.
>Seams that Chain is only for Struts 1.2 ?
>or 1.3, which is based on Servlet2.2
I believe that we reached consensus that it would be ok to move
Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked
on the release of a GA 1.2.x Struts so as to minimize any need to
apply patches across both branches.
Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true
that we are just waiting for commons-validator 1.1.4 to be marked
"GA"? The other bugs all seem to be marked for 1.3 except one which
is underspecified.
Should we somehow annotate this page:
http://wiki.apache.org/struts/StrutsRelease125 to indicate that there
isn't going to be a 1.2.5 release? Or should we have a vote on it
even though 1.2.6 is brewing?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale and Chain
Posted by Ted Husted <hu...@apache.org>.
MailReader/Chain is a work-in-progress, which I'll move over to our new Apps subproject as soon as 1.2.6 is ready to roll. (First things first!)
Agility isn't an application, it's a whiteboard, and there isn't any code to build.
There will probably be more to add to the cookbook (chapter-chain.html) once Mailreader/Chain is complete.
-Ted.
On Fri, 19 Nov 2004 15:07:59 -0700, BaTien Duong wrote:
>�Craig:
>
>�Thanks for a good start. The 2 apps under commons-chain seem to be
>�built by Ted? Ted, do you have further instructions besides chapter-
>�chain.html?
>
>�Thanks.
>
>�BaTien
>�DBGROUPS
>
>
>�Craig McClanahan wrote:
>
>>�On Fri, 19 Nov 2004 13:44:47 -0700, BaTien Duong
>>�<ba...@dbgroups.com>�wrote:
>>
>>
>>>�Greetings:
>>>
>>>�I want to prototype commons-chain in shale. I saw 2 apps:
>>>�agility and mailreader. I was able to build commons-chain.jar
>>>�using ant. I modify maven project.xml of the 2 apps and run
>>>�maven default successfully. But there is no war file of the
>>>�above apps. Look like it has not done anything.
>>>
>>>
>>�I didn't build that part of the commons-chain repository, so I'll
>>�have to take a look ... it'll probably be over the weekend.
>>
>>
>>>�Could someone show me how to build the 2 apps using commons-
>>>�chain? Craig, do you have any preliminary instruction on the
>>>�commons-chain in Shale?
>>>
>>
>>�Let's assume that you have defined the business logic for a
>>�particular form submit as a chain named "foo" in the default
>>�catalog. �JSF will call the action method for your submit button
>>�after validations have been successful, and after all the model
>>�values have been updated into your ViewController bean. �So, what
>>�you need to do for chain is build up a Context object, and either
>>�include the ViewController bean itself (so your business logic
>>�can pull stuff out, but that makes it dependent on the
>>�ViewController APIs), or pass the data on in some other fashion
>>�like a Map. �So, this is only one way to do it:
>>
>>�(1) Create a context to use:
>>
>>�Context context = new
>>�FacesWebContext(FacesContext.getCurrentInstance());
>>
>>�(2) Pass in the input field values from your ViewController (this
>>�is sorta cheating):
>>
>>�context.put("viewController", this);
>>
>>�(3) Get an instance of the command and execute it:
>>
>>�Command command = CatalogFactory.getInstance().getCommand("foo");
>>�command.execute(context);
>>
>>�(4) Pull out the logical outcome to be used for navigation and
>>�return it: (Assumes your business logic stored something under
>>�this attribute)
>>
>>�String outcome = (String) context.get("outcome");
>>�return outcome;
>>
>>�For your business logic, you'll want to model it as either a
>>�single Command, or as a Chain -- if you want to make the business
>>�logic independent of web tier APIs you'd take the input context
>>�argument as a Context and treat it like a Map to get and put
>>�stuff.
>>�Alternatively, you can cast it to FacesWebContext if you wanted
>>�typesafe access to all the extra attributes that defines.
>>
>>�To configure your catalog of available commands and chains, you
>>�can use the org.apache.commons.chain.web.ChainListener class (a
>>�ServletContextListener) to set everything up from XML
>>�descriptions, although this is not required. �That's what my
>>�examples (and the one in struts-chain) use.
>>
>>
>>>�Thanks
>>>
>>>�BaTien
>>>�DBGROUPS
>>>
>>>
>>�Craig
>>
>>�------------------------------------------------------------------
>>�--- 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: Shale and Chain
Posted by BaTien Duong <ba...@dbgroups.com>.
Craig:
Thanks for a good start. The 2 apps under commons-chain seem to be built
by Ted? Ted, do you have further instructions besides chapter-chain.html?
Thanks.
BaTien
DBGROUPS
Craig McClanahan wrote:
>On Fri, 19 Nov 2004 13:44:47 -0700, BaTien Duong
><ba...@dbgroups.com> wrote:
>
>
>>Greetings:
>>
>>I want to prototype commons-chain in shale. I saw 2 apps: agility and
>>mailreader. I was able to build commons-chain.jar using ant. I modify
>>maven project.xml of the 2 apps and run maven default successfully. But
>>there is no war file of the above apps. Look like it has not done anything.
>>
>>
>>
>
>I didn't build that part of the commons-chain repository, so I'll have
>to take a look ... it'll probably be over the weekend.
>
>
>
>>Could someone show me how to build the 2 apps using commons-chain?
>>Craig, do you have any preliminary instruction on the commons-chain in
>>Shale?
>>
>>
>
>Let's assume that you have defined the business logic for a particular
>form submit as a chain named "foo" in the default catalog. JSF will
>call the action method for your submit button after validations have
>been successful, and after all the model values have been updated into
>your ViewController bean. So, what you need to do for chain is build
>up a Context object, and either include the ViewController bean itself
>(so your business logic can pull stuff out, but that makes it
>dependent on the ViewController APIs), or pass the data on in some
>other fashion like a Map. So, this is only one way to do it:
>
>(1) Create a context to use:
>
> Context context = new FacesWebContext(FacesContext.getCurrentInstance());
>
>(2) Pass in the input field values from your ViewController (this is
>sorta cheating):
>
> context.put("viewController", this);
>
>(3) Get an instance of the command and execute it:
>
> Command command = CatalogFactory.getInstance().getCommand("foo");
> command.execute(context);
>
>(4) Pull out the logical outcome to be used for navigation and return it:
> (Assumes your business logic stored something under this attribute)
>
> String outcome = (String) context.get("outcome");
> return outcome;
>
>For your business logic, you'll want to model it as either a single
>Command, or as a Chain -- if you want to make the business logic
>independent of web tier APIs you'd take the input context argument as
>a Context and treat it like a Map to get and put stuff.
>Alternatively, you can cast it to FacesWebContext if you wanted
>typesafe access to all the extra attributes that defines.
>
>To configure your catalog of available commands and chains, you can
>use the org.apache.commons.chain.web.ChainListener class (a
>ServletContextListener) to set everything up from XML descriptions,
>although this is not required. That's what my examples (and the one
>in struts-chain) use.
>
>
>
>>Thanks
>>
>>BaTien
>>DBGROUPS
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>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: Shale and Chain
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 19 Nov 2004 13:44:47 -0700, BaTien Duong
<ba...@dbgroups.com> wrote:
> Greetings:
>
> I want to prototype commons-chain in shale. I saw 2 apps: agility and
> mailreader. I was able to build commons-chain.jar using ant. I modify
> maven project.xml of the 2 apps and run maven default successfully. But
> there is no war file of the above apps. Look like it has not done anything.
>
I didn't build that part of the commons-chain repository, so I'll have
to take a look ... it'll probably be over the weekend.
> Could someone show me how to build the 2 apps using commons-chain?
> Craig, do you have any preliminary instruction on the commons-chain in
> Shale?
Let's assume that you have defined the business logic for a particular
form submit as a chain named "foo" in the default catalog. JSF will
call the action method for your submit button after validations have
been successful, and after all the model values have been updated into
your ViewController bean. So, what you need to do for chain is build
up a Context object, and either include the ViewController bean itself
(so your business logic can pull stuff out, but that makes it
dependent on the ViewController APIs), or pass the data on in some
other fashion like a Map. So, this is only one way to do it:
(1) Create a context to use:
Context context = new FacesWebContext(FacesContext.getCurrentInstance());
(2) Pass in the input field values from your ViewController (this is
sorta cheating):
context.put("viewController", this);
(3) Get an instance of the command and execute it:
Command command = CatalogFactory.getInstance().getCommand("foo");
command.execute(context);
(4) Pull out the logical outcome to be used for navigation and return it:
(Assumes your business logic stored something under this attribute)
String outcome = (String) context.get("outcome");
return outcome;
For your business logic, you'll want to model it as either a single
Command, or as a Chain -- if you want to make the business logic
independent of web tier APIs you'd take the input context argument as
a Context and treat it like a Map to get and put stuff.
Alternatively, you can cast it to FacesWebContext if you wanted
typesafe access to all the extra attributes that defines.
To configure your catalog of available commands and chains, you can
use the org.apache.commons.chain.web.ChainListener class (a
ServletContextListener) to set everything up from XML descriptions,
although this is not required. That's what my examples (and the one
in struts-chain) use.
>
> Thanks
>
> BaTien
> DBGROUPS
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale and Chain
Posted by BaTien Duong <ba...@dbgroups.com>.
Greetings:
I want to prototype commons-chain in shale. I saw 2 apps: agility and
mailreader. I was able to build commons-chain.jar using ant. I modify
maven project.xml of the 2 apps and run maven default successfully. But
there is no war file of the above apps. Look like it has not done anything.
Could someone show me how to build the 2 apps using commons-chain?
Craig, do you have any preliminary instruction on the commons-chain in
Shale?
Thanks
BaTien
DBGROUPS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale vs. Struts-Chain
Posted by Craig McClanahan <cr...@gmail.com>.
Miscellaneous comments inline.
On Thu, 18 Nov 2004 13:48:39 +0100, Matthias Wessendorf
<ma...@matthias-wessendorf.de> wrote:
> Hi all,
>
> I read the docs on subversion about Shale.
> Well, a very interessting point.
> However, I asked myself how it is related
> to Struts/Commons - Chain. (The Proposal aka Jericho)
>
> Has Struts Shale no relationship to (Struts/Commons)-Chain?
There is no particular relationship between Shale and *Struts*-Chain,
which is designed to decompose the Struts 1.x request processor into
little pieces. However, there is no reason you couldn't use *Commons*
Chain inside a Shale environment in several different ways:
* When using a Filter as the application controller, compose
all the pre-request and post-request processing to be performed
into chains, so that you only need to configure a single filter
in your web.xml file.
* Have your action event handlers (for things like submit buttons)
delegate to business logic that is expressed in a chain, rather
than executing it directly.
that is composed in a chain
> Seams that Chain is only for Struts 1.2 ?
> or 1.3, which is based on Servlet2.2
That's correct.
> And Shale, that will be on top of Servlet2.4,
> will use Filter for CoR, isn't it?
That is the proposal, yes -- although, as I remarked above, you can
implement CoR inside a filter, in addition to the ability to use more
than one Filter. It remains to be seen which model is easier to
program to, and for users to configure.
>
> Last but not least, the IoC (or dependency injection)
> from Spring or Hivemind will be *included* into Struts / Shale?
I believe that developers using a modern framework will expect an IoC
solution to be included. Interestingly, the managed beans APIs in JSF
provide "setter injection" IoC support already -- however, that may
not be sufficient for everyone's needs.
If the Shale core code itself was limited to just managed beans, then
we could support incorporation of pretty much any IoC architecture by
leveraging JSF's pluggability APIs. For example, the Spring folks
have already built a JSF VariableResolver that allows the managed
beans facility to instantiate Spring beans transparently. That's
pretty cool.
Applications, of course, could integrate directly with the IoC
framework if they wanted to.
>
> Thanks for helping to clear my picture ;-)
>
> Greetings,
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale vs. Struts-Chain
Posted by Ted Husted <hu...@apache.org>.
On Thu, 18 Nov 2004 13:48:39 +0100, Matthias Wessendorf wrote:
>
> Has Struts Shale no relationship to (Struts/Commons)-Chain?
Technically, there only relationship between Struts and Shale is that they are both standards-based web application frameworks originated by Craig McClanahan :)
I saw your post to the MyFaces list regarding Shale, Matthais, and it will be interesting to see how the MyFaces community responds.
Given that Apache MyFaces now hosts generic JSF components, like JSF Tiles, an obvious question is whether Shale would be a better fit as a MyFaces subproject.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org