struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: setupItems posted to Bugzilla
Date Wed, 09 Mar 2005 22:03:08 GMT
Michael Rasmussen wrote:
> Frank,
>   Maybe I am in the minority, I don't know, but I thought the whole
> point of version numbers to keep track of what features exist in a
> certain package of released code?  

By that logic, one could argue that adding a new feature to the 1.2 
branch is perfectly acceptable, even if it is never added to 1.3.

> No new work will ever be done on
> 1.1 because 1.2 is the current branch of struts.  As soon as 1.3 is
> out the door that will be the case for 1.2.  New feature development
> on every product happens in the latest branch.  Why are you surprised
> or concerned by this?  

I'm not surprised by this.  But I also don't see why that PRECLUDES new 
features in a previous version.

> If you want features that are not in the version you
> have to use, create those features and use them.  

In other words, fork off ;)

The thing is, this is open-source, which means that if there are people 
willing to do the work, NO version of something should ever die.  If I 
am willing to continue adding features to the 1.2 branch (assuming I can 
get a committer to apply it), why should we say as a blanket statement 
that "sorry, too bad, the 1.2 branch is not being supported, so go use 
1.3"?  That seems like a statement completely contrary to the idea of 
open-source and community development.

Well, the bottom-line here is that regardless of what the community may 
want, I can't do anything about it "officially" because I am not a 
committer.  That's kind of the end of the story, isn't it?  Note that I 
AM NOT saying the community wants my solution.  Certainly some do, but I 
don't presume to speak for everyone.  The Struts team in fact DOES 
though, as is their right.  If they say Chain is the answer, then it's 
the answer.  I can disagree until I'm blue in the face, but at the end 
of the day, who cares?

But let's be clear: my only real recourse is to release my own version 
of Struts, which is contrary to trying to make it better and I won't do 
that, so that's that really.  I tried, but in the end THAT doesn't 
matter either.

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

> On Wed, 9 Mar 2005 14:04:05 -0500 (EST), Frank W. Zammetti
> <> wrote:
>>All of your answers boil down to (a) use 1.2.x and add Chain yourself, or
>>(b) use 1.3.  For some shops (mine as a case in point), (b) isn't an
>>option, and won't be for a long time.  And either option forces you to use
>>Chain, which not everyone is going to be comfortable with, except in the
>>case of 1.3 where using it implicitly means using Chain and you understand
>>that going in.
>>I hope I'm not coming across confrontational as that is not my intent.
>>But, if anything prior to 1.3 is now considered dead (or on life support I
>>suppose), which is how I interpret the comment about it being relegated to
>>bug fixes (it's an evolutionary dead end I think is clear), then that is
>>an interesting tidbit for all to be clear on because it means that no new
>>features will be added to anything other than 1.3.  Am I misrepresenting
>>reality with that statement? :)
>>I can only make the proposals, or create my own fork, which I wouldn't do.
>> It's up to you folks to decide what gets in and what doesn't, and I
>>recognize that.  But, if you are saying that NOTHING new (nothing
>>substantial anyway) is going to be added to 1.x, that's bad news for me,
>>and probably others as well.
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>On Wed, March 9, 2005 1:42 pm, Martin Cooper said:
>>>On Wed, 9 Mar 2005 13:20:17 -0500 (EST), Frank W. Zammetti
>>><> wrote:
>>>>Well, a couple of points:
>>>>(1) The idea of "page prep" or "setup functionality" seems to get asked
>>>>lot on the lists.  There are numerous ways to handle it or course, many
>>>>which were debated in the preceeding threads (I'd have to go dig through
>>>>the archives myself to reference them).  It is asked enough in fact that
>>>>"standard" solution built in to Struts makes a lot of sense to me, and
>>>>others that were involved in the discussion.  I believe this proposal is
>>>>very flexible implementation.  Probably not perfect, but an open-ended
>>>>to achieve these goals.
>>>The use of Chain will (has!) become a standard part of Struts in
>>>Struts 1.3. I'm not sure I see the need for more than one standard
>>>>(2) ChainAction... I'm not aware of it.  Is it new in 1.3?  If so, I for
>>>>one am not yet interested in using 1.3.  In fact, we're still using 1.1
>>>>here at work, so a solution for "older" Struts versions is nice.
>>>ChainAction is part of Struts Chain, which has been in the Contrib
>>>area of Struts for rather a long time now. Maybe even back as far as
>>>1.1 - I don't recall. Struts Chain is what has been merged into the
>>>main trunk for Struts 1.3. That includes the composable request
>>>processor and several chain-based actions, such as ChainAction,
>>>amongst other things. You might want to take a look.
>>>>(3) Using Commons Chain with 1.2.6 (and presumably older versions
>>>>I'm sure that works well, but not everyone likes the idea of adding any
>>>>extra dependencies they don't feel they want to to their projects.  I'd
>>>>prefer a capability similar to this be built in to Struts itself.  I'm
>>>>alone on this, based on the opinions of those working around me.
>>>Well, I don't see the type of thing you're proposing as part of a
>>>Struts 1.2.x release, since that's pretty much relegated to bug fixes
>>>at this point, as we push towards 1.3. Chain is already built into
>>>Struts 1.3, including the ChainAction I referred to. So the choices
>>>would appear to be Struts 1.2.x + Struts Chain or Struts 1.3 with no
>>>additional dependencies.
>>>>(4) Options.  They are good :)  This can be considered another tool in
>>>>toolbox.  Maybe use it, maybe don't.  Sure to be good in some cases,
>>>>probably not in others.  I'd hate to be forced to use something like
>>>>for this, I'd rather have the option (not saying you *have* to use Chain
>>>>now to accomplish this of course).  But again, the idea of a "standard"
>>>>approach is worth something I believe.
>>>Yes, I agree that a standard approach is good. I also believe that
>>>Chain is becoming the standard approach in Struts 1.3. Joe has been
>>>doing some great work on making it as well integrated and easy to use
>>>as possible, and I think it's looking great. I'd be extremely
>>>reluctant to add yet another way of doing things as a "standard" on
>>>top of that. Options *can* be good, but they can also confuse people.
>>>Martin Cooper
>>>>Frank W. Zammetti
>>>>Founder and Chief Software Architect
>>>>Omnytex Technologies
>>>>On Wed, March 9, 2005 12:59 pm, Martin Cooper said:
>>>>>First of all, I have to admit that I am *way* behind on any thread
>>>>>that has posts of more than about a dozen lines, and have not followed
>>>>>the threads that led to this proposal.
>>>>>That said, I don't understand why this is necessary. Why not just use
>>>>>ChainAction, and do this with Commands, instead of adding yet another
>>>>>mechanism to do it? In my day job, we're using Struts 1.2.6 + Struts
>>>>>Chain for this, and that's working very well for us.
>>>>>Please feel free to point me to a message in the archive that explains
>>>>>this, rather than repeating the explanation. I'm sure I can't be the
>>>>>first to wonder this. ;-)
>>>>>Martin Cooper
>>>>>On Wed, 9 Mar 2005 11:43:21 -0500 (EST), Frank W. Zammetti
>>>>><> wrote:
>>>>>>For those that expressed an interest (one or two with baited breath
>>>>as I
>>>>>>recall!), and even for those that didn't catch the previous threads,
>>>>>>just added a Bugzilla ticket for the initial posting of setupItems.
>>>>>>In short, this is an addition to Struts (1.2.4) that allows for
>>>>>>functionality to be declaratively added to action mappings and
>>>>>>In other words, you can do something like the following:
>>>>>><action path="/myPage"
>>>>>>  <setupItem setupClass="com.mycompany.myapp.setups.SetupClass"
>>>>>>setupMethod="setupMethod1" />
>>>>>>This would result in SetupClass.setupMethod1() being called right
>>>>>>execute() of MyPageAction is called (it gets passed the request
>>>>>>You can do whatever you like in this setup class, but I believe this
>>>>>>be good for things like populating dropdowns and such that need to
>>>>>>regardless of what happens in the Action.
>>>>>>You can add a setupItem to forwards as well, both global and local,
>>>>>>you can add as many as you like.  They will all be executed, in the
>>>>>>they appear.  Also, for the forwards, the setupItems listed for the
>>>>>>mapping will executed first, followed by those for the forwards
>>>>>>by your Action only, AFTER execute() completes.
>>>>>>The ticket contains a ZIP archive with a complete example webapp that
>>>>>>shows numerous example of this in a number of variants.  It also
>>>>>>the complete source for the webapp as well as the changes made to
>>>>>>Lastly, it includes an updated struts.jar that you should be able
>>>>>>in an existing application, updated your struts-config.xml file, and
>>>>>>you go.  Be sure to check out the readme.txt file in WEB-INF/src for
>>>>>>details if you give this a try.
>>>>>>That's that.  Let's see what people think...
>>>>>>Frank W. Zammetti
>>>>>>Founder and Chief Software Architect
>>>>>>Omnytex Technologies
>>>>>>To unsubscribe, e-mail:
>>>>>>For additional commands, e-mail:
>>>>>To unsubscribe, e-mail:
>>>>>For additional commands, e-mail:
>>>To unsubscribe, e-mail:
>>>For additional commands, e-mail:
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message