You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/12/23 20:58:57 UTC
Tying Up Loose Ends
Given a little time to work on Struts (finally), I'd like to tackle the
top two bugs (based on severity) in our remaining list:
* 14669 -- reset() in DynaActionForm acts the same as in ActionForm
* 14800 -- Fix initialization bug and size parameter to form-property
What I propose to do for 14669 is based on the patch proposed by Peter
Pilgrim, but with the "loaded" property renamed to "cleared" -- for
consistency with the method name clear() -- and the "cleared" property
stuff being protected instead of public. For general users of action
forms, I don't see why the cleared state would be relevant, although it
might to advanced DynaActionForm subclasses. The clear() methods will, as
proposed, be public so that application logic can call them as needed.
For 14800, I think we do need the "size" attribute to pre-initialize
arrays to a fixed size when the "initial" attribute is not present. I'm
less persuaded by the "potential security hole" argument related to
copying the initial values for an array) because the only values that are
shared are the constants that were parsed from the XML configuration in
the first place. For the vast majority of practical uses of this (Strings
and primitives) the underlying objects are immutable and modifications to
the property value in one form bean won't be propogated to other form
beans anyway. But I'll certainly look into this more as I dive in to the
code. (The placement of the actual logic for this will be updated to
reflect the changes made for 14669, and will be added as a separate
commit.)
The change for 14669, in particular, is not backwards compatible -- which
is always something that makes me squeamish. However, the discussions of
this problem on STRUTS-DEV have convinced me that the original design was
in fact flawed, and that this does in fact trip up new Struts users, as
well as making the conversion from old-style ActionForm subclasses to
DynaActionForm more complicated than it should be. Therefore, I think
it's justified to go ahead and make the changes now.
Comments? Thoughts?
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by Eddie Bush <ek...@swbell.net>.
What I've been doing is going to the query page, selecting all
severities except enhancement - then selecting struts. I believe this
is the method Martin was using, though he could tell you better - as
best I can recall, that is the method to use.
Ted Husted wrote:
>Is it not the idea that the computers are suppose to do the
>counting for us? =:0) =:0)
>
>12/24/2002 2:45:11 PM, "Craig R. McClanahan" <cr...@apache.org>
>wrote:
>
>
>>Count the non-enhancement ones :-).
>>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by Ted Husted <hu...@apache.org>.
Is it not the idea that the computers are suppose to do the
counting for us? =:0) =:0)
12/24/2002 2:45:11 PM, "Craig R. McClanahan" <cr...@apache.org>
wrote:
>
>Count the non-enhancement ones :-).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 24 Dec 2002, Ted Husted wrote:
> Date: Tue, 24 Dec 2002 14:27:11 -0500
> From: Ted Husted <hu...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Tying Up Loose Ends
>
> Yes, but it doesn't return 14 tickets when I run it, it returns
> 45.
Count the non-enhancement ones :-).
>
> -T.
>
Craig
> 12/24/2002 2:07:00 PM, "Craig R. McClanahan" <cr...@apache.org>
> wrote:
>
> >
> >
> >On Tue, 24 Dec 2002, Ted Husted wrote:
> >
> >> Date: Tue, 24 Dec 2002 09:17:20 -0500
> >> From: Ted Husted <hu...@apache.org>
> >> Reply-To: Struts Developers List <struts-
> dev@jakarta.apache.org>
> >> To: Struts Developers List <st...@jakarta.apache.org>
> >> Subject: Re: Tying Up Loose Ends
> >>
> >> 12/23/2002 5:31:07 PM, "Craig R. McClanahan"
> <cr...@apache.org>
> >> wrote:
> >> >14, counting some that are documentation related.
> >>
> >> Craig, could you please post an active link to the Bugzilla
> query
> >> that produces this list on the Roadmap, so that we are all on
> the
> >> same page.
> >>
> >
> >There's already such a query on the roadmap page:
> >
> > http://jakarta.apache.org/struts/status.html
> >
> >It's in the last bullet under Struts 1.1:
> >
> > * Other routine changes per Bugzilla and Dev List
> >
> >I'm going to modify the text so that it's more obvious, though.
> >
> >> -Ted.
> >>
> >
> >Craig
> >
> >
> >--
> >To unsubscribe, e-mail: <mailto:struts-dev-
> unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail: <mailto:struts-dev-
> help@jakarta.apache.org>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by Ted Husted <hu...@apache.org>.
Yes, but it doesn't return 14 tickets when I run it, it returns
45.
-T.
12/24/2002 2:07:00 PM, "Craig R. McClanahan" <cr...@apache.org>
wrote:
>
>
>On Tue, 24 Dec 2002, Ted Husted wrote:
>
>> Date: Tue, 24 Dec 2002 09:17:20 -0500
>> From: Ted Husted <hu...@apache.org>
>> Reply-To: Struts Developers List <struts-
dev@jakarta.apache.org>
>> To: Struts Developers List <st...@jakarta.apache.org>
>> Subject: Re: Tying Up Loose Ends
>>
>> 12/23/2002 5:31:07 PM, "Craig R. McClanahan"
<cr...@apache.org>
>> wrote:
>> >14, counting some that are documentation related.
>>
>> Craig, could you please post an active link to the Bugzilla
query
>> that produces this list on the Roadmap, so that we are all on
the
>> same page.
>>
>
>There's already such a query on the roadmap page:
>
> http://jakarta.apache.org/struts/status.html
>
>It's in the last bullet under Struts 1.1:
>
> * Other routine changes per Bugzilla and Dev List
>
>I'm going to modify the text so that it's more obvious, though.
>
>> -Ted.
>>
>
>Craig
>
>
>--
>To unsubscribe, e-mail: <mailto:struts-dev-
unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:struts-dev-
help@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 24 Dec 2002, Ted Husted wrote:
> Date: Tue, 24 Dec 2002 09:17:20 -0500
> From: Ted Husted <hu...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Tying Up Loose Ends
>
> 12/23/2002 5:31:07 PM, "Craig R. McClanahan" <cr...@apache.org>
> wrote:
> >14, counting some that are documentation related.
>
> Craig, could you please post an active link to the Bugzilla query
> that produces this list on the Roadmap, so that we are all on the
> same page.
>
There's already such a query on the roadmap page:
http://jakarta.apache.org/struts/status.html
It's in the last bullet under Struts 1.1:
* Other routine changes per Bugzilla and Dev List
I'm going to modify the text so that it's more obvious, though.
> -Ted.
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by Ted Husted <hu...@apache.org>.
12/23/2002 5:31:07 PM, "Craig R. McClanahan" <cr...@apache.org>
wrote:
>14, counting some that are documentation related.
Craig, could you please post an active link to the Bugzilla query
that produces this list on the Roadmap, so that we are all on the
same page.
-Ted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 23 Dec 2002, Peter A. Pilgrim wrote:
> Date: Mon, 23 Dec 2002 22:13:24 +0000
> From: Peter A. Pilgrim <pe...@xenonsoft.demon.co.uk>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Tying Up Loose Ends
>
> Craig R. McClanahan wrote:
> > Given a little time to work on Struts (finally), I'd like to tackle the
> > top two bugs (based on severity) in our remaining list:
> >
> > * 14669 -- reset() in DynaActionForm acts the same as in ActionForm
> >
> > * 14800 -- Fix initialization bug and size parameter to form-property
> >
> > What I propose to do for 14669 is based on the patch proposed by Peter
> > Pilgrim, but with the "loaded" property renamed to "cleared" -- for
> > consistency with the method name clear() -- and the "cleared" property
> > stuff being protected instead of public. For general users of action
> > forms, I don't see why the cleared state would be relevant, although it
> > might to advanced DynaActionForm subclasses. The clear() methods will, as
> > proposed, be public so that application logic can call them as needed.
> >
>
> Well, Craig, I made it public because may be you want to "clear" the
> attributes back to the default initial values in a action controller.
> I think I am repeated what you just wrote.
>
> When I added the "loaded" / "cleared" attribute I was not sure whether
> to make it `public' or `protected'. I called the attributed "loaded"
> because the DynaActionForm loads the states XML config files. I almost
> called it "configured". Also I assume logically and semantically
> that ` DAF.isLoaded() != DAF.isCleared() '
>
It turns out that I didn't actually need a boolean property at all. I
just modified the RequestUtils.createActionForm() method to call
initialize() when it created a new form bean instance, so there wasn't any
need for a special flag. As long as applications use this same factory
method (which is recommended), they won't have to make their custom
reset() methods worry about this either.
I also figured that initialize() was better than clear() because it
corresponded to the "initial" attribute on <form-property> elements.
> --////--
>
> How many bugs are out standing now?
>
14, counting some that are documentation related.
> --
> Peter Pilgrim
> ServerSide Java Specialist
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>.
Craig R. McClanahan wrote:
> Given a little time to work on Struts (finally), I'd like to tackle the
> top two bugs (based on severity) in our remaining list:
>
> * 14669 -- reset() in DynaActionForm acts the same as in ActionForm
>
> * 14800 -- Fix initialization bug and size parameter to form-property
>
> What I propose to do for 14669 is based on the patch proposed by Peter
> Pilgrim, but with the "loaded" property renamed to "cleared" -- for
> consistency with the method name clear() -- and the "cleared" property
> stuff being protected instead of public. For general users of action
> forms, I don't see why the cleared state would be relevant, although it
> might to advanced DynaActionForm subclasses. The clear() methods will, as
> proposed, be public so that application logic can call them as needed.
>
Well, Craig, I made it public because may be you want to "clear" the
attributes back to the default initial values in a action controller.
I think I am repeated what you just wrote.
When I added the "loaded" / "cleared" attribute I was not sure whether
to make it `public' or `protected'. I called the attributed "loaded"
because the DynaActionForm loads the states XML config files. I almost
called it "configured". Also I assume logically and semantically
that ` DAF.isLoaded() != DAF.isCleared() '
--////--
How many bugs are out standing now?
--
Peter Pilgrim
ServerSide Java Specialist
My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tying Up Loose Ends
Posted by James Turner <tu...@blackbear.com>.
BTW, if the other piece of size= (setting the values to new instances of
the base class) is implemented, then I withdraw this, because then you
wouldn't need to use a converter to create arrays of mutable objects,
you could do it with size=. Then the initial= argument could be used
only for things that it's OK to clone.
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tying Up Loose Ends
Posted by James Turner <tu...@blackbear.com>.
> * The application has registered a custom Converter that creates
> an array of objects of the appropriate type from the String-valued
> "initial" attribute.
>
> * The application then modifies the values on a per-user or
> per-request
> basis (rather than using this technique to initialize some sort of
> readonly collection).
>
> While the above conditions are technically possible, they
> don't seem like the kind of thing that real applications
> would use the "initial" attribute of a <form-property>
> element for. Is there some common use case that I am missing?
>
> > Martin Cooper
>
> Craig
Here's the specific example I ran into (and also why I proposed size= in
the first place.) (Sorry for the verboseness of this, I want to make it
clear...)
Dependent.java
package com.benefit.association;
public class Dependent {
private String lastName;
private String firstName;
private String middleName;
private String dob;
private String gender;
private String relationship;
public void reset() {
lastName = null;
firstName = null;
middleName = null;
dob = null;
gender = null;
relationship = null;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public String getLastName() {
return lastName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getFirstName() {
return firstName;
}
public void setMiddleName(String middleName) {
this.middleName = middleName;
}
public String getMiddleName() {
return middleName;
}
public void setDob(String dob) {
this.dob = dob;
}
public String getDob() {
return dob;
}
public void setGender(String gender) {
this.gender = gender;
}
public String getGender() {
return gender;
}
public void setRelationship(String relationship) {
this.relationship = relationship;
}
public String getRelationship() {
return relationship;
}
}
struts-config.xml
<form-bean name="dependentlistForm"
type="com.benefit.association.struts.forms.ValidatorForm">
<form-property name="dependents"
type="com.benefit.association.Dependent[]"
initial="{"", "", "", "", "", "", "", "", "", ""}
/>
</form-bean>
.
.
.
<action name="dependentlistForm"
type="com.benefit.association.struts.actions.DependentListAction"
input="/dependentlist.jsp" scope="session"
path="/dependentlist">
<forward name="/kea/coverage" path="/kea/coverage.jsp" />
<forward name="/krta/coverage" path="/krta/coverage.jsp" />
<forward name="/swof/coverage" path="/swof/coverage.jsp" />
</action>
And my dependentlist.jsp has in part:
<html:form action="/dependentlist">
<TABLE><TR><TD>Last Name</TD><TD>First
Name</TD><TD>MI</TD><TD>Relationship</TD><TD>Date of
Birth<BR>MM/DD/YYYY</TD><TD>Gender</TD></TR>
<logic:iterate id="dependents" name="dependentlistForm"
property="dependents" type="com.benefit.association.Dependent">
<TR><TD><html:text name="dependents" property="lastName" indexed="true"
maxlength="30" size="30"/></TD>
<TD><html:text name="dependents" property="firstName" indexed="true"
maxlength="30" size="30"/></TD>
<TD><html:text name="dependents" property="middleName" indexed="true"
maxlength="1" size="1"/></TD>
<TD><html:select name="dependents" property="relationship"
indexed="true">
<html:option value="S">Spouse</html:option>
<html:option value="C">Child</html:option>
</html:select></TD>
<TD><html:text name="dependents" property="dob" indexed="true"
maxlength="10" size="10"/></TD>
<TD><html:select name="dependents" property="gender" indexed="true">
<html:option value="M">Male</html:option>
<html:option value="F">Female</html:option>
</html:select></TD></TR>
</logic:iterate>
What happens (with cloning) is this:
The first time through, FormPropertyConfig correctly calls the converter
I had registered for Dependent (which creates a new instance regardless
of the initialization value) and correctly sets up the array. At the
end of the registration process, the form is removed from session scope.
However, the next time someone requests a dependentlistForm, it gets a
cloned copy of the dependents array, which means that although the array
is new, the elements are the same as from the last form, including
values filled in by the user.
Does this clarify how it can happen?
James
Now I have a form:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 23 Dec 2002, Martin Cooper wrote:
> Date: Mon, 23 Dec 2002 14:59:50 -0800 (PST)
> From: Martin Cooper <ma...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Tying Up Loose Ends
>
>
>
> On Mon, 23 Dec 2002, Craig R. McClanahan wrote:
>
> > Given a little time to work on Struts (finally), I'd like to tackle the
> > top two bugs (based on severity) in our remaining list:
> >
> > * 14669 -- reset() in DynaActionForm acts the same as in ActionForm
> >
> > * 14800 -- Fix initialization bug and size parameter to form-property
> >
> > What I propose to do for 14669 is based on the patch proposed by Peter
> > Pilgrim, but with the "loaded" property renamed to "cleared" -- for
> > consistency with the method name clear() -- and the "cleared" property
> > stuff being protected instead of public. For general users of action
> > forms, I don't see why the cleared state would be relevant, although it
> > might to advanced DynaActionForm subclasses. The clear() methods will, as
> > proposed, be public so that application logic can call them as needed.
> >
> > For 14800, I think we do need the "size" attribute to pre-initialize
> > arrays to a fixed size when the "initial" attribute is not present. I'm
> > less persuaded by the "potential security hole" argument related to
> > copying the initial values for an array) because the only values that are
> > shared are the constants that were parsed from the XML configuration in
> > the first place. For the vast majority of practical uses of this (Strings
> > and primitives) the underlying objects are immutable and modifications to
> > the property value in one form bean won't be propogated to other form
> > beans anyway. But I'll certainly look into this more as I dive in to the
> > code. (The placement of the actual logic for this will be updated to
> > reflect the changes made for 14669, and will be added as a separate
> > commit.)
>
> I agree that the "size" attribute is useful. I also think it would be
> useful to be able to initialise all of the elements of an array to an
> initial value - perhaps something like this:
>
> <form-property name="foo"
> type="java.lang.String[]"
> size="10"
> initial="1"/>
>
> so that each element of the array is initialised to "1". This would be a
> bit less error-prone than listing out N entries in the "initial"
> attribute. However, it's really an enhancement (to an enhancement :), so
> we can leave it for later.
>
I'm not totally convinced about the utility of a repeating list, but agree
that it fits the "later" category.
> For the other part of the bug report, the concern seems to be that, if the
> specified type is something like a customer bean, which might have a
> credit card property, then the object created to hold the initial values
> would be the same object that is populated from one user's request, and
> that those changed values would also be used to populate another user's
> response, thus exposing one user's credit card number to another user.
>
OK, let's explore this particular scenario. Assume we have a form bean
whose configuration looks like this:
<form-bean name="customer"
type="org.apache.struts.action.DynaActionForm">
...
<form-property name="sensitive" type="java.lang.String[]"
iniital="{secret-1, secret-2, secret-3}"/>
...
</form-bean>
Now, when you call RequestUtils.createActionForm(), you get a
DynaActionForm instance of this class with an indexed property named
"sensitive". The array will have three elements, with the values
"secret-1", "secret-2", and "secret-3".
Note, however, that the *array* holding these values is unique per form
bean instance (because of the cloning logic in the current
implementation). So, what happens when an Action that sets up this form
bean before forwarding to an input page does something like this:
ActionForm form = RequestUtils.createActionForm(...);
form.setIndexedProperty(form, "sensitive", "New secret-2 Value", 1);
or, equivalently:
ActionForm form = RequestUtils.createActionForm(...);
((DynaBean) form).set("sensitive", 1, "New secret-2 Value");
This modification will *only* affect *this* form bean instance, not all of
them, because Strings are immutable. The net effect is that the array
will hold "secret-1", "New secret-2 Value", "secret-3" for this particular
instance, but no other instances will be affected. (Hint: this is why
the array cloning is done in the first place -- my original implementation
did not clone, and the arrays themselves were shared, which is bad).
> I haven't dug into the code sufficiently to determine whether or not this
> is a real problem, but if it is, I would have expected all sorts of other
> problems with DynaBeans to have surfaced before now, resulting from the
> same underlying cause.
I believe that the only scenario that can cause a problem would exhibit
all of the following:
* The element class for the indexed property is mutable. This means
that arrays of Strings or primitives (of any standard type) are immune
to any problems, and that covers nearly every common case for form bean
properties that I can think of.
* The application has registered a custom Converter that creates
an array of objects of the appropriate type from the String-valued
"initial" attribute.
* The application then modifies the values on a per-user or per-request
basis (rather than using this technique to initialize some sort of
readonly collection).
While the above conditions are technically possible, they don't seem like
the kind of thing that real applications would use the "initial" attribute
of a <form-property> element for. Is there some common use case that I am
missing?
> Martin Cooper
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tying Up Loose Ends
Posted by Martin Cooper <ma...@apache.org>.
On Mon, 23 Dec 2002, Craig R. McClanahan wrote:
> Given a little time to work on Struts (finally), I'd like to tackle the
> top two bugs (based on severity) in our remaining list:
>
> * 14669 -- reset() in DynaActionForm acts the same as in ActionForm
>
> * 14800 -- Fix initialization bug and size parameter to form-property
>
> What I propose to do for 14669 is based on the patch proposed by Peter
> Pilgrim, but with the "loaded" property renamed to "cleared" -- for
> consistency with the method name clear() -- and the "cleared" property
> stuff being protected instead of public. For general users of action
> forms, I don't see why the cleared state would be relevant, although it
> might to advanced DynaActionForm subclasses. The clear() methods will, as
> proposed, be public so that application logic can call them as needed.
>
> For 14800, I think we do need the "size" attribute to pre-initialize
> arrays to a fixed size when the "initial" attribute is not present. I'm
> less persuaded by the "potential security hole" argument related to
> copying the initial values for an array) because the only values that are
> shared are the constants that were parsed from the XML configuration in
> the first place. For the vast majority of practical uses of this (Strings
> and primitives) the underlying objects are immutable and modifications to
> the property value in one form bean won't be propogated to other form
> beans anyway. But I'll certainly look into this more as I dive in to the
> code. (The placement of the actual logic for this will be updated to
> reflect the changes made for 14669, and will be added as a separate
> commit.)
I agree that the "size" attribute is useful. I also think it would be
useful to be able to initialise all of the elements of an array to an
initial value - perhaps something like this:
<form-property name="foo"
type="java.lang.String[]"
size="10"
initial="1"/>
so that each element of the array is initialised to "1". This would be a
bit less error-prone than listing out N entries in the "initial"
attribute. However, it's really an enhancement (to an enhancement :), so
we can leave it for later.
For the other part of the bug report, the concern seems to be that, if the
specified type is something like a customer bean, which might have a
credit card property, then the object created to hold the initial values
would be the same object that is populated from one user's request, and
that those changed values would also be used to populate another user's
response, thus exposing one user's credit card number to another user.
I haven't dug into the code sufficiently to determine whether or not this
is a real problem, but if it is, I would have expected all sorts of other
problems with DynaBeans to have surfaced before now, resulting from the
same underlying cause.
--
Martin Cooper
>
> The change for 14669, in particular, is not backwards compatible -- which
> is always something that makes me squeamish. However, the discussions of
> this problem on STRUTS-DEV have convinced me that the original design was
> in fact flawed, and that this does in fact trip up new Struts users, as
> well as making the conversion from old-style ActionForm subclasses to
> DynaActionForm more complicated than it should be. Therefore, I think
> it's justified to go ahead and make the changes now.
>
> Comments? Thoughts?
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>