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: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
