struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Action, dispatch, etc.
Date Tue, 20 Feb 2007 21:59:52 GMT
On Tue, February 20, 2007 4:42 pm, Michael Jouravlev wrote:
> Hi Frank, I've taken this discussion offline if you don't mind, but if
> you like we can bring ig back to the list. We had this argument
> before, my reasons are the same.

Let's go ahead and bring it back to the list, ok?  It's a worth-wild
discussion for public consumption I think.

> With current shift from s1 to s2 Paul and me are free (well, not
> completely, but we have more leeway) to implement features we like,
> features we always wanted but could not add to the core because of
> resistance of several core committers.

That's cool, I'm glad you have that leeway.  But your not answering the
question I've asked, which again is simply why not just create a subclass
of Action that does what you want?  If there's some technical reason this
isn't viable, I'm all ears.  But so far I haven't heard that.  Isn't it
still "in the core" if it's included with S1?  I don't think it has to be
a modified Action class to be in the core, does it?  This is my only
point, I AM NOT arguing with the basic concept of what your trying to do,
and I get the feeling you think I am.

> Whether s1 will stay viable after 1.4 release or not I want to make
> changes I always wanted, and now I can do this being a committer :-)

But your dealing with a code base that has a huge legacy of applications
written on it, so you have to be especially careful what you do with it,
right?  That means considering all angles that you can, and I'm simply
bringing up another.

> My changes do not break backward compatibility so I don't see why you
> or anyone else should be worried. If 1.4 won't be used in the field
> then why would one care about its features?

I'm not worried... I fully understand what your proposing doesn't break
compatibility, I completely take your word for it that that's the case. 
But, I don't think compatibility is the only concern.  For instance, isn't
there, even if a miniscule, amount of overhead added to each request?  If
I understood the flow you posted on the JIRA ticket, there would have to
be... even if it's a minute amount, you have to remember how many
high-volume sites out there count on the level of performance the base
Action class provides now.  If you go and add to that, you conceivably
impact them., whereas a new Action type doesn't.  That's just one thing,
but that's my point: why not simply a new type of Action?  Why is it so
important to modify the Action class itself?  That is, and has been, my
only question here.


> On 2/20/07, Frank W. Zammetti (JIRA) <> wrote:
>>     [
>> ]
>> Frank W. Zammetti commented on STR-2940:
>> ----------------------------------------
>> I'm not arguing what your trying to do... I'm simply asking two
>> intermingled questions here:
>> Why does what your trying to do have to involve modifying Action?  Why
>> isn't simply creating a new kind of Action sufficient?
>> I imagine that when DispatchAction was first introduced, a similar
>> question was asked... why not just add dispatching functionality to
>> Action and be done with it?  Well, somewhere along the line, someone
>> decided a second kind of Action was the better answer.  I'm asking the
>> same question here, not debating whether what your proposing is a good
>> idea or not.  It seems to me, if it's a new descendant of Action, then
>> that question is moot anyway.
>> If your only goal is to push a new mindset on people, which frankly
>> seems to be the case based on what you said in the previous comment, I
>> would contend that's not the right reason to do this, considering the
>> tremendous number of existing Struts apps that have to be maintained.
>> A related piont, although one I hesitate to make frankly... One could
>> certainly make the argument that S1 is quickly becoming legacy given the
>> advent of S2, and in that frame of mind, I don't think major
>> architectural changes (which this is, whether developers are forced to
>> deal with it or not) should be undertaken lightly.

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

View raw message