That makes sense, cloning as Niall does sound right (shucks, had it working and done!).
Simple question: how should the mapping be cloned? I mean, clearly when I override processMapping() I'll just call the super version and then clone what I recieve and return that, but how should I literally do the clone? clone() in Object it's just a shallow copy, correct? Is org.apache.commons.beanutils.BeanUtils.cloneBean() the right answer? Just want to be sure I'm not missing something else I should be using. Thanks again for all the help guys, this all I think makes my project quite a bit more useful! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, February 2, 2005 2:37 pm, Joe Germuska said: > I would recommend against unfreezing the ActionMappings; they are > shared throughout the application, and you have no way of knowing > whether some non-webservice request may come along in a minute and > get the same ActionMapping instance and get stuck with an incorrect > value for the "input" property. > > As Niall mentioned (and I thought I did too, but maybe I just thought > about mentioning it! ;-) ), it is possible to clone the ActionMapping > and use a new instance for each request. The precedent for this is > already established by the ActionConfigMatcher which supports > wild-card action mappings. > > Joe > > > At 2:23 PM -0500 2/2/05, [EMAIL PROTECTED] wrote: >>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] > > > -- > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
