i might put that freeze in a finally block, if you're gonna do something nasty,
better make sure you leave no footprints. :)


if (request is a web service) {
  try {
    ACUnfreezer.unfreeze(mapping);
    mapping.setInput(the new JSP to go to in case of validation errors);
  } finally {
    mapping.freeze(); // Just for good measure
  }
}


Quoting [EMAIL PROTECTED]:

> 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]

Reply via email to