GOT IT!
But, this might be the worst piece of hackery I've ever done. Check it out...
Joe's last response spurred me to realize that if I could override the input
field of the ActionMapping, I could do what I want. As I thought,
processPreprocess() fires before processValidate(), which means I can identify
a Web Service request in processValidate() based on some attributes I set in
processPreprocess().
The problem as I discovered is that I can't just call setInput() in
processValidate() because the configuration is frozen at that point. And,
since the RequestProcessor isn't in the same package as ActionConfig (where
setInput() is found), I couldn't call setInput() since it's protected.
So, enter the hackery of the following class...
package org.apache.struts.config;
import org.apache.struts.action.ActionMapping;
public class ACUnfreezer {
public static void unfreeze(ActionMapping mapping) {
mapping.configured = false;
}
}
So, in processValidate(), I simply do:
if (request is a web service) [
ACUnfreezer.unfreeze(mapping);
mapping.setInput(the new JSP to go to in case of validation errors);
mapping.freeze(); // Just for good measure
}
return super.processValidate(request, response, form, mapping);
So, regular requests work as before, and the Web Service requests will be
redirected if validation errors occur. Beautiful!
In an EXTREMELY hacky kind of way!
Thanks for the talkback Paul and Joe, I'm not sure how long it would have taken
on my own to get to this solution, if at all. Of course, I suppose that means
you have to accept some of the blame for such a hack-job :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> This actually stimulated another thought. Perhaps instead of
> overriding process validate, you could arrange to have your
> ActionMappings dynamically instantiated with the correct value for
> "input" (assuming that you can know it before you do the validation.)
>
> There is nothing sacred about the original instances of ActionMapping
> which are created by processing the struts-config file. The wildcard
> mapping support results in dynamic construction of ActionMappings
> which have parameters replaced according to the wildcard match.
>
> You could either use your own ModuleConfig implementation with a
> custom implementation of findActionConfig(path) or, if the
> determination of the input depends on request data as well as the
> path, override processMapping in the RequestProcessor.
>
> I still think using the ComposableRequestProcessor is an easier solution!
>
> Joe
>
>
> At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>>Frank,
>>
>>I am not sure of why you need this solution. I never came across your
>> need
>>-- and perhaps because I never encountered the problem.
>>
>>I can't imagine why you would want to dynamically control the input page.
>>For instance, I use MappingDispatchAction and each action entry has its
>> own
>>specified input and success forward.
>>
>>Is your question actually posed by a misdesign?
>>
>>Thanks,
>>Paul
>>
>>-----Original Message-----
>>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, February 02, 2005 12:39 PM
>>To: dev@struts.apache.org
>>Subject: Extending RequestProcessor to handle validation errors
>>
>>
>>Hi folks... I'm working on an update of my Struts Web Services project,
>>and I can't seem to work out how to do something...
>>
>>What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>>validation errors occur that will OVERRIDE whatever might be configured
>> in
>>the action mapping. In other words... in a normal application,
>> validation
>>errors occur and we get forwarded back to the input page. I want to be
>>able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>>I looked at overriding the processValidate() method of RequestProcessor,
>>but I don't see how that can work... Looking at the source of the
>> original
>>RP (v1.1 this all is) I see that it does the forward and then returns a
>>boolean, true if no errors occur or false otherwise, so it doesn't look
>>like I have the opportunity to do something like the following
>>psuedo-code:
>>
>>myOverriden_ProcessValidate() {
>>
>> boolean b = super.processValidate();
>> if (!b) {
>> forward to my jsp
>> }
>>
>>}
>>
>>... because by the time I hit my check of b, the forward or redirect has
>>already been done. Is it possible to override the forward or redirect
>>that the super.processValidate() could do? I didn't think so. Am I
>>missing the obvious somewhere on how to do this, or maybe I'm barking up
>>the wrong tree to begin with? Thanks all!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>------------------------------------------------------------------------------
>>Notice: This e-mail message, together with any attachments,
>>contains information of Merck & Co., Inc. (One Merck Drive,
>>Whitehouse Station, New Jersey, USA 08889), and/or its affiliates
>>(which may be known outside the United States as Merck Frosst, Merck
>>Sharp & Dohme or MSD and in Japan, as Banyu) that may be
>>confidential, proprietary copyrighted and/or legally privileged. It
>>is intended solely for the use of the individual or entity named on
>>this message. If you are not the intended recipient, and have
>>received this message in error, please notify us immediately by
>>reply e-mail and then delete it from your system.
>>------------------------------------------------------------------------------
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
