Why is token checking only available when control has passed to the Action class?

[St...@national.com.au]

Hi all,

I have a fairly involved problem surrounding token checking for request
reload management.

There are various methods available in the Action class such as saveToken,
resetToken and isTokenValid which are all very useful in helping manage
reload requests.

All these methods operate off a token stored in the session, which these
methods access directly from the request object.  There is no dependence on
the form object for these methods.

A problem arises when, during the normal processing of a request, the form
object is modified in such a way that array elements in the form are
removed.
For example, an array of transactions in the initial request has 10
elements in it, during action processing this array is resized due to some
business rule down to 5 transactions.  The array has only 5 elements in it
now.
The next screen is displayed.
If a reload request is sent now, the number of transactions in the request
is still 10 but the form object only has a transaction array with 5
elements in it.  When the request processor attempts to populate the form
object with the request data an ArrayIndexOutOfBoundsException occurs which
is understandable but very undesirable.

Should the token functions be moved into the org.apache.struts.util
.RequestUtil class so that they are available to the RequestProcessor?

We can then check for reloads prior to the form object being populated in
the processPreprocess method in the RequestProcessor.


Very interested in anyone's thoughts on this.

It looks like we will have to set something up ourselves to do this but if
Struts itself could change to accommodate this it would be very useful.

Regards,

Steve Akins
Team Leader, Frameworks, J2EE Engineering
Development Centre
Financial Services Australia Technology


( +61 3 8641 2846 2 +61 3 8641 4152 : steve_akins@national.com.au


National Australia Bank Limited
4th Floor/ 500 Bourke St
Melbourne, Victoria 3000
__________________________________________________________________________
The information contained in this email communication may be confidential.
You
should only read, disclose, re-transmit, copy, distribute, act in reliance
on or
commercialise the information if you are authorised to do so. If you are
not the
intended recipient of this email communication, please notify us
immediately by
email to NABpost@national.com.au or reply by email direct to the sender
and then destroy any electronic or paper copy of this message.  Any views
expressed in this email communication are those of the individual sender,
except
where the sender specifically states them to be the views of a member of
the
National Australia Bank Group of companies.  The National Australia Bank
Group
of companies does not represent, warrant or guarantee that the integrity of
this
communication has been maintained nor that the communication is free of
errors,
virus or interference.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>