/moduleA.do <------- an action that starts with
/module <------ a different module's name
was causing control to be shifted to the other module. There were also cases where similarly-named modules (/foo and /foobar) would exhibit this same behavior. This was caused by a bug in RequestProcessor.selectApplication - which has been fixed, as noted.
The contextRelative attribute *should* be the ticket. I haven't seen any problems with it since the patch. I don't remember exactly which build it was that fixed that, so you may want to grab a recent nightly (last nights, for example - I'm not aware of any problems with that one).
The thing to bear in mind is that you *must* go through an *action* to switch modules. Going to a JSP will not do it. The controller *must* be involved, because it has to put the configuration out into the request. I think that's what's going on here. Let me know if you continue to experience difficulties.
Taylor, Jason wrote:
I'll vouch for the fact that contextRelative works, and should work
according to your included configuration-- barring some bug in a build more
recent than the one I'm using (unlikely).
Have you tried a different name for either the default or sub app's path? I
know there have been some bugs surrounding the path matching with sub-apps--
Eddie Bush is the person I've seen discussing this most recently...
-- Eddie Bush
-- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
