DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16442>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16442 JSP in non-default module cannot call actions in that module Summary: JSP in non-default module cannot call actions in that module Product: Struts Version: 1.1 Beta 3 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A JSP in a non-default module cannot reference actions in that module. This is most noticeable when using an <html:form> tag to submit form data. When attempting to call the action, the URL is incorrectly mapped against the default module instead of the sub-module the page is in. For example, suppose one has a module (mymodule) configured in the web.xml as follows: <init-param> <param-name>config/mymodule</param-name> <param-value>/WEB-INF/struts-mymodule-config.xml</param-value> </init-param> Further suppose that an action-mapping (myaction) is configured in that module as follows: <action path="/myaction" type="mypackage.MyAction"/> Finally, suppose that a JSP (/mymodule/mypage.jsp) exists with the following: <html:form action="myaction.do"> Upon submission of that form, the following exception is thrown: [ServletException in:mypage.jsp] Cannot retrieve mapping for action /myaction If one copies the action-mapping into the default module (i.e. /WEB-INF/struts-config.xml) then all is well. This suggests that the JSP environment is unaware of the existence of any modules other than the default. Upon examination of the Struts framework, the reason for this becomes obvious. Action requests are pre-processed by Struts prior to handing off to the application code. One of the pre-processing steps is a call to org.apache.struts.util.RequestUtils.selectModule(), which determines the module being invoked and stores the corresponding ModuleConfig object in the request. If the module is the default, no ModuleConfig is stored. JSPs on the other hand are not pre-processed by Struts, but are instead handled directly by the JSP engine. Thus, no ModuleConfig is ever pre-loaded into the request. When a JSP needs to know what module it's in, it calls org.apache.struts.util.RequestUtils.getModuleConfig(), which attempts to retrieve the ModuleConfig from the request. Not finding it, it defaults to the one in the ServletContext (the default module). The problem here is that getModuleConfig() is making the assumption that if no ModuleConfig object is in the request then none has been configured. In reality, there are two reasons why this object might not be present, one being that it simply hasn't been loaded yet. Here is a patch implementing a quick fix for this problem. It's not an ideal solution (the URL is parsed every time getModuleConfig() is called), but I've tested that it works. --- RequestUtils.java.orig Sun Jan 26 14:09:31 2003 +++ RequestUtils.java Sun Jan 26 14:32:56 2003 @@ -1673,6 +1673,7 @@ * @since 1.1b3 */ public static ModuleConfig getModuleConfig(PageContext pageContext) { + selectModule((HttpServletRequest)pageContext.getRequest(),pageContext.getServletContext()); ModuleConfig moduleConfig = (ModuleConfig) pageContext.getRequest().getAttribute(Globals.MODULE_KEY); if (moduleConfig == null) { // Backwards compatibility hack -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
