DO NOT REPLY [Bug 16442] New: - JSP in non-default module cannot call actions in that module

[bu...@apache.org]

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: struts-dev@jakarta.apache.org
        ReportedBy: milo@cyberlifelabs.com


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>