On Tue, 16 Nov 2004 12:22:08 -0500, Bill Siggelkow <[EMAIL PROTECTED]> wrote: > I believe your observations are correct. If you want to avoid the > "special features" you could conditionally skip them if the request is a > SwitchAction to the new module ... just one idea. >
Ok, thanks for the confirmation. The custom request processor is 'off limits' to me (I think adding conditional code to this is what you are suggesting?), but I might be able to switch which module is which. Meaning, if I restructure my app so that the current default module becomes the second module, then I am clear to switch into that one whenever I need to, but start out with a new default module using a standard request processor. At least I am testing that theory now. I think it will basically just entail renaming the struts-config.xml definitions in the web.xml, and adding the switch action mapping to the new default module. Hopefully, this won't have an affect on the inner workings within the original default module. > > > Susan Bradeen wrote: > > > I have a Struts application that uses a custom request processor. Now > > I am trying to add a module so that I have part of the app using the > > standard request processor. The custom request processor makes checks > > on things I don't want checked when entering into my second module. Is > > it true that in order to switch modules from the original app (default > > module) to my second module, I am still making a pass through the > > default request processor, before forwarding to my second module? > > > > My understanding is that I put this in my default module struts-config: > > > > <action-mappings> > > <action path="/toModule" > > type="org.apache.struts.actions.SwitchAction"/> > > ... > > </action-mappings> > > > > Then, using the following I can switch to an action mapping listed in > > my second module: > > > > http://localhost:8080/toModule.do?prefix=/moduleB&page=/index.do > > > > However, since the switch action mapping is in the default module, > > that (switch) action is actually processed using the default module > > (custom) request processor. Am I correct on this? At least this is the > > behavior I appear to be seeing. So, if I am trying to avoid using this > > custom request processor to access features of my second module, then > > I need to go about this in a different way. Right? > > > > Hopefully my question is clear. Thanks for any input. > > Susan Bradeen > > > --------------------------------------------------------------------- > 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]
