We actually have no validation XML files (we're setting error fields
manually). We're not performing validation using that approach, but we
want to remain open to doing so in the future. The validation interceptor
is in the struts-default stack, which is what our packages extend from.
From what Dave said it sounds like short circuiting is not our solution.
Is there perhaps a setting we're missing on the chaining interceptor to
tell it not to call validation/input on downstream chained actions?
I read a similar thread where someone suggested reordering the interceptor
stack so that validation is above chain, because when chain is first it
copies action errors into the next action in the chain. I've started
making a custom interceptor stack to try this, but my guess is the action
that JSP result won't see the action errors from the one action that *does*
set action error messages because they won't get copied down the stack.
It seems like the framework is calling input on any downstream chained
action if action errors are placed on the value stack by an upstream
chained action. We even have some actions called via s:action (execute
results = true) in the JSP result and it's trying to call input even on
those actions.
-B
Martin Gainty
<[EMAIL PROTECTED]
com> To
Struts Users Mailing List
09/17/2008 11:21 <user@struts.apache.org>
AM cc
Subject
Please respond to RE: [S2] Action chaining and
"Struts Users validation problem
Mailing List"
<[EMAIL PROTECTED]
he.org>
check your validators.xml to see if your short-circuit attribute is set to
true
The invokemethod grants the Interceptor the power to short-circuiting the
Action Invocation.
Instead of calling invoke, the Interceptor can
return a result String and
bypass any remaining Interceptors on the stack and the Action's execute
method.
e.g.
<validators>
<!-- Field Validators for email field -->
<field name="email">
<field-validator type="required" short-circuit="true">
you'll want to set short-circuit="false" to allow interceptors and execute
to be invoked
http://struts.apache.org/2.x/docs/understanding-interceptors.html
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official
business of Sender. This transmission is of a confidential nature and
Sender does not endorse distribution to any party other than intended
recipient. Sender does not necessarily endorse content contained within
this transmission.
> Subject: [S2] Action chaining and validation problem
> To: user@struts.apache.org
> From: Becky.L.O'[EMAIL PROTECTED]
> Date: Wed, 17 Sep 2008 10:30:06 -0700
>
>
> Without going into a lot of detail, suffice to say our application
benefits
> from action chaning, and we are using it in the documented way.
>
> We've begun to go through and add the validation to some actions, but we
> have run into a snag with validation and action chaining.
>
> Whenever one action in the chain encounters an error as a result of
> validation all other actions are affected. Struts then calls the input
> method on all downstream actions. However, some actions don't override
> input, and by calling only the input method on those actions Struts is
not
> calling the intended method (be it execute() or a named method), and
those
> actions are not executing properly. Not only are downstream actions
> affected, but simple actions called using the <s:action tag are also
> affected in the same way.
>
> It seems like, whenever there are action errors in the value stack,
> everything passed that value stack gets a call to input.
>
> Has anyone else run in to this kind of issue with action chaining and
> validation?
>
> Thanks,
> -B
>
>
>
> ---------------------------------------------------------------------
> This message, together with any attachments, is
> intended only for the use of the individual or entity
> to which it is addressed. It may contain information
> that is confidential and prohibited from disclosure.
> If you are not the intended recipient, you are hereby
> notified that any dissemination or copying of this
> message or any attachment is strictly prohibited. If
> you have received this message in error, please notify
> the original sender immediately by telephone or by
> return e-mail and delete this message, along with any
> attachments, from your computer. Thank you.
>
> ---------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
_________________________________________________________________
Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
---------------------------------------------------------------------
This message, together with any attachments, is
intended only for the use of the individual or entity
to which it is addressed. It may contain information
that is confidential and prohibited from disclosure.
If you are not the intended recipient, you are hereby
notified that any dissemination or copying of this
message or any attachment is strictly prohibited. If
you have received this message in error, please notify
the original sender immediately by telephone or by
return e-mail and delete this message, along with any
attachments, from your computer. Thank you.
---------------------------------------------------------------------
