Pluto
  1. Pluto
  2. PLUTO-490

Cannot deploy portlets to ROOT context

    Details

      Description

      Deploying portlets to ROOT fails because of improper detection and handling of the "" context path.

      DefaultApplicationIdResolver#resolveApplicationId(ServletContext) returns "/hostName" for the root context instead of "", where "hostName" is the name of the host containing the context (typically "localhost"). The program will seem to work normally except when HttpServletRequest.getContextPath() is called such as by the JSTL url tag. That method would then return the incorrect value of "/hostName".

      Even when the context path is correctly detected as "", the portletId created by PortletWindowConfig#createPortletId(String, String, String) cannot by parsed by PortletWindowConfig#fromId(String) because the latter throws an exception if the id starts with ".".

      1. pluto_490.diff
        3 kB
        Steven Broadbridge
      2. pluto_rootContext.patch
        5 kB
        Eric Dalquist

        Activity

        Steven Broadbridge created issue -
        Steven Broadbridge made changes -
        Field Original Value New Value
        Attachment pluto_490.diff [ 12385746 ]
        Hide
        Craig Doremus added a comment -

        The solution for DefaultApplicationIdResolver appears to be Tomcat specific. Is there a way to make it more generic? We want our portlet container to be deployable in a variety of web containers.

        Show
        Craig Doremus added a comment - The solution for DefaultApplicationIdResolver appears to be Tomcat specific. Is there a way to make it more generic? We want our portlet container to be deployable in a variety of web containers.
        Hide
        Steven Broadbridge added a comment -

        The only universal solution is to require the use of a sevlet api 2.5 application server when deploying to the root context. Then DefaultApplicationIdResolver will never be called. Deducing the context path given just the ServletContext object will always be an implementation specific hack.

        Show
        Steven Broadbridge added a comment - The only universal solution is to require the use of a sevlet api 2.5 application server when deploying to the root context. Then DefaultApplicationIdResolver will never be called. Deducing the context path given just the ServletContext object will always be an implementation specific hack.
        Hide
        Steven Broadbridge added a comment - - edited

        I suggest patching org.apache.pluto.core.PortletContextManager.computeContextPath(ServletContext) to log a warning when the computed path's authority is DEFAULT. The problem now is how to identify the context in the warning.

        Update: PortletContextManager already logs a warning when the servlet API is 2.4 or below so further warnings would be redundant.

        Show
        Steven Broadbridge added a comment - - edited I suggest patching org.apache.pluto.core.PortletContextManager.computeContextPath(ServletContext) to log a warning when the computed path's authority is DEFAULT. The problem now is how to identify the context in the warning. Update: PortletContextManager already logs a warning when the servlet API is 2.4 or below so further warnings would be redundant.
        Eric Dalquist made changes -
        Assignee Eric Dalquist [ edalquist ]
        Fix Version/s 1.1.6 [ 12313075 ]
        Hide
        Craig Doremus added a comment -

        We should note in the javadoc to DefaultApplicationIdResolver that this class is an implementation for a Tomcat container that supports version 2.4 of the servlet spec (Tomcat 5.5) and that other servlet 2.4 containers need to implement the ApplicationIdResolver interface to support Pluto deployment.

        Show
        Craig Doremus added a comment - We should note in the javadoc to DefaultApplicationIdResolver that this class is an implementation for a Tomcat container that supports version 2.4 of the servlet spec (Tomcat 5.5) and that other servlet 2.4 containers need to implement the ApplicationIdResolver interface to support Pluto deployment.
        Craig Doremus made changes -
        Fix Version/s 2.0.0 [ 12312914 ]
        Fix Version/s 2.0-refactoring [ 12313313 ]
        Hide
        Eric Dalquist added a comment -

        Perhaps we provide an additional Tomcat5ApplicationIdResolver and include a note about using it in the warning issued by DefaultApplicationIdResolver when run under Servlet 2.4. I'm going to be doing some testing with uPortal (using Pluto 1.1.5) in the root context of Tomcat today and I'll base my next steps on this from that testing.

        Show
        Eric Dalquist added a comment - Perhaps we provide an additional Tomcat5ApplicationIdResolver and include a note about using it in the warning issued by DefaultApplicationIdResolver when run under Servlet 2.4. I'm going to be doing some testing with uPortal (using Pluto 1.1.5) in the root context of Tomcat today and I'll base my next steps on this from that testing.
        Hide
        Eric Dalquist added a comment - - edited

        In testing this there may be a bug in Tomcat 6, ServletContext.getContextPath() returns "" for the root context. The JavaDocs for getContextPath states "The path starts with a "/" character but does not end with a "/" character" and you can only find a RequestDispatcher for the root context by requesting it for "/". I've filed: https://issues.apache.org/bugzilla/show_bug.cgi?id=45484

        Show
        Eric Dalquist added a comment - - edited In testing this there may be a bug in Tomcat 6, ServletContext.getContextPath() returns "" for the root context. The JavaDocs for getContextPath states "The path starts with a "/" character but does not end with a "/" character" and you can only find a RequestDispatcher for the root context by requesting it for "/". I've filed: https://issues.apache.org/bugzilla/show_bug.cgi?id=45484
        Hide
        Eric Dalquist added a comment -

        Just confirming that in TC6 getContextPath() returning "" is causing pluto problems and I have a proposed fix in the bug I linked to above. I'll do some TC55 testing next and see what the situation is there.

        Show
        Eric Dalquist added a comment - Just confirming that in TC6 getContextPath() returning "" is causing pluto problems and I have a proposed fix in the bug I linked to above. I'll do some TC55 testing next and see what the situation is there.
        Hide
        Steven Broadbridge added a comment - - edited

        There is an inconsistency in the Servlet API concerning the definition of the root context path.

        From ServetContext#getContextPath():
        The context path always comes first in a request URI. The path starts with a "/" character but does not end with a "/" character. For servlets in the default (root) context, this method returns "". [This is word-for-word the same definition as in HttpServletRequest]

        From ServletContext#getContext(String):
        The given path must be begin with "/", is interpreted relative to the server's document root and is matched against the context roots of other web applications hosted on this container.

        Considering this, we cannot assume that only Tomcat has problems with getContext(""). One solution is to patch PortletContextManager#getPortletContext(ServletContext, String) to substitute "/" for "". Another is to have PortletWindowConfig#createPortletId do the swap.

        Show
        Steven Broadbridge added a comment - - edited There is an inconsistency in the Servlet API concerning the definition of the root context path. From ServetContext#getContextPath(): The context path always comes first in a request URI. The path starts with a "/" character but does not end with a "/" character. For servlets in the default (root) context, this method returns "". [This is word-for-word the same definition as in HttpServletRequest] From ServletContext#getContext(String): The given path must be begin with "/", is interpreted relative to the server's document root and is matched against the context roots of other web applications hosted on this container. Considering this, we cannot assume that only Tomcat has problems with getContext(""). One solution is to patch PortletContextManager#getPortletContext(ServletContext, String) to substitute "/" for "". Another is to have PortletWindowConfig#createPortletId do the swap.
        Hide
        Eric Dalquist added a comment -

        Thanks for pointing that out. I think the fix will end up being in PortletContextManager so that it works for all portals that use Pluto as this will affect every portal. I'll continue with applying that change and your patch and post a final diff here for everyone to comment on.

        Show
        Eric Dalquist added a comment - Thanks for pointing that out. I think the fix will end up being in PortletContextManager so that it works for all portals that use Pluto as this will affect every portal. I'll continue with applying that change and your patch and post a final diff here for everyone to comment on.
        Steven Broadbridge made changes -
        Comment [ Instead of a check and substitute, another possibility is to append "/PlutoInvoker" to whatever is the context path is before calling ServletContext#getContext(String). But the simple check might be more efficient. ]
        Hide
        Eric Dalquist added a comment -

        This patch fixes the root context resolution under Servlet 2.4 in Tomcat and fixes the cross-context lookup of the root context. For non-tomcat containers the functionality of the context name resolution done by DefaultApplicationIdResolver should not change. If the patch looks good to Steve & Craig I will apply it.

        Show
        Eric Dalquist added a comment - This patch fixes the root context resolution under Servlet 2.4 in Tomcat and fixes the cross-context lookup of the root context. For non-tomcat containers the functionality of the context name resolution done by DefaultApplicationIdResolver should not change. If the patch looks good to Steve & Craig I will apply it.
        Eric Dalquist made changes -
        Attachment pluto_rootContext.patch [ 12386919 ]
        Hide
        Steven Broadbridge added a comment -

        Looks good to me.

        Show
        Steven Broadbridge added a comment - Looks good to me.
        Hide
        Craig Doremus added a comment -

        Looks good to me too. Thanks for your hard work on this issue!

        Show
        Craig Doremus added a comment - Looks good to me too. Thanks for your hard work on this issue!
        Hide
        Eric Dalquist added a comment -

        Applied in all three locations.

        Show
        Eric Dalquist added a comment - Applied in all three locations.
        Eric Dalquist made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12435049 ] Default workflow, editable Closed status [ 12565322 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12565322 ] jira [ 12585990 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        15d 9h 37m 1 Eric Dalquist 25/Jul/08 23:13

          People

          • Assignee:
            Eric Dalquist
            Reporter:
            Steven Broadbridge
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development