PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-1911

Relationship between portlet-name, PortletServlet mapping and requestdispatching to ServletFilters

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Won't Fix
    • Affects Version/s: 5.2.1, 5.2.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      5.2 branch revision 25818
      Liferay's internal portlet container (does not happen on Sun's portlet container)
    • Similar Issues:
      Show 5 results 

      Description

      We're experiencing problems with dispatched request when a resourcerequest is called.
      We are using Wicket to build our portlets and this is working ok.

      However I have a question about the relationship between the portlet-name in portlet.xml, PortletServlet, the RequestDispatcher and servletfilters mapping .

      The only way we can get WicketPortlets to work is when the portlet-name (in portlet.xml) is exactly the same as the servletfilter mapping url-pattern in web.xml of the servletfilter. Example of what does work:

      web.xml
      ...
      <filter>
      <filter-name>example1</filter-name>
      <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
      <init-param>
      <param-name>applicationClassName</param-name>
      <param-value>com.maxxton.portlet.example.WicketApplication</param-value>
      </init-param>
      </filter>

      <filter-mapping>
      <filter-name>example1</filter-name>
      <url-pattern>/example/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
      <dispatcher>FORWARD</dispatcher>
      <dispatcher>INCLUDE</dispatcher>
      </filter-mapping>
      ...

      portlet.xml
      ...
      <portlet>
      <description>As simple as it gets.</description>
      <portlet-name>example</portlet-name>
      <display-name>example</display-name>
      <portlet-info>
      <title>Example 1 Portlet</title>
      <keywords>Example 1</keywords>
      </portlet-info>
      </portlet>
      ...

      However if I change the portlet name to something else. The RequestDispatcher never finds the the filter when using a ResourceRequest.
      Example od what doesn't:

      <filter>
      <filter-name>example1</filter-name>
      <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
      <init-param>
      <param-name>applicationClassName</param-name>
      <param-value>com.maxxton.portlet.example.WicketApplication</param-value>
      </init-param>
      </filter>

      <filter-mapping>
      <filter-name>example1</filter-name>
      <url-pattern>/exampleportlet/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
      <dispatcher>FORWARD</dispatcher>
      <dispatcher>INCLUDE</dispatcher>
      </filter-mapping>
      ...

      portlet.xml
      ...
      <portlet>
      <description>As simple as it gets.</description>
      <portlet-name>example</portlet-name>
      <display-name>example</display-name>
      <portlet-info>
      <title>Example 1 Portlet</title>
      <keywords>Example 1</keywords>
      </portlet-info>
      </portlet>
      ...

      The error that I get then is:
      "The requested resource (/example/exampleportlet/) is not available" (thrown in Tomcat)

      Is this intentional? As having a different portlet-name vs filter-mapping does work for Pluto/Jetspeed/Suns Portlet-Container)

        Activity

        Hide
        Wilfred Springer added a comment - - Restricted to

        I've been trying to apply the rules suggested above, but I still can't get it working. But now I am getting really confused about the reference to another revision that I should be using. It's not clear if this other revision (not the official release) is expected to be a workaround, or if it's only referenced here to have the guarantee to reproduce the error. (Or else what?)

        Does anybody have a real workaround?

        For:

        • Liferay/JBoss 5.2.1
        • Wicket 1.4-rc2
        Show
        Wilfred Springer added a comment - - Restricted to I've been trying to apply the rules suggested above, but I still can't get it working. But now I am getting really confused about the reference to another revision that I should be using. It's not clear if this other revision (not the official release) is expected to be a workaround, or if it's only referenced here to have the guarantee to reproduce the error. (Or else what?) Does anybody have a real workaround? For: Liferay/JBoss 5.2.1 Wicket 1.4-rc2
        Hide
        Raymond Auge added a comment - - Restricted to

        Hello All,

        I've tested the provided portlet using the internal portlet container on liferay 5.1.x and trunk as of at latest rev. 29138.

        This is the setup you need: portletName, wicketFilterPath, filter-mapping/url-pattern must all match.

        I know some of you tried this and it didn't work.

        1) One reason is that liferay will "alter" the portletName in order to prevent some JS issues. SO, you need to have a look into the web.xml once Liferay has deployed the plugin and look to see what the resulting servlet-mapping/url-pattern value is for the generated PortletServlet config. Use that value in the wicketFilterPath and filter-mapping/url-pattern and the filter will work.

        2) You SHOULD name the plugin so that it ends with "-portlet". Otherwise it might not generate the proper servlet mapping for the portlet at all.

        i.e. I renamed example-noerror-1.0-SNAPSHOT.war to example-noerror-portlet.war, changed the configs, deployed and it worked in both versions of the portal I tested (the counter incremented).

        Show
        Raymond Auge added a comment - - Restricted to Hello All, I've tested the provided portlet using the internal portlet container on liferay 5.1.x and trunk as of at latest rev. 29138. This is the setup you need: portletName, wicketFilterPath, filter-mapping/url-pattern must all match. I know some of you tried this and it didn't work. 1) One reason is that liferay will "alter" the portletName in order to prevent some JS issues. SO, you need to have a look into the web.xml once Liferay has deployed the plugin and look to see what the resulting servlet-mapping/url-pattern value is for the generated PortletServlet config. Use that value in the wicketFilterPath and filter-mapping/url-pattern and the filter will work. 2) You SHOULD name the plugin so that it ends with "-portlet". Otherwise it might not generate the proper servlet mapping for the portlet at all. i.e. I renamed example-noerror-1.0-SNAPSHOT.war to example-noerror-portlet.war, changed the configs, deployed and it worked in both versions of the portal I tested (the counter incremented).
        Hide
        Antony Stubbs added a comment - - Restricted to

        If this is really required, IMO the developer interface must provide feedback.

        Can you make is to that
        1) if there is a missing filter-mapping that matches the portal definition, then there is a severe warning? (i.e. use hasn't setup properly)

        2) if the portletName is "altered" there is a warning, so there is an indication of what is going on?

        3) by plugin do you mean portlet? can you again give a warning or error out if there is a portal definition which does not end with "-portlet"

        Show
        Antony Stubbs added a comment - - Restricted to If this is really required, IMO the developer interface must provide feedback. Can you make is to that 1) if there is a missing filter-mapping that matches the portal definition, then there is a severe warning? (i.e. use hasn't setup properly) 2) if the portletName is "altered" there is a warning, so there is an indication of what is going on? 3) by plugin do you mean portlet? can you again give a warning or error out if there is a portal definition which does not end with "-portlet"
        Hide
        Raymond Auge added a comment - - Restricted to

        Regarding 3) I myself hate the fact that we have this naming "convention" on our various plugins (of which portlet is one). I think we should get rid of that and rely purely on descriptors.

        I think the solution to 1) and 2) would be to look for filters that don't have a servlet mapping, and map those to the PortletServlet. That would solve it I think.

        What do you think? But I'm not 100% sure why the path lookup is failing in the first place. I'd like to see the wicket code which dispatches to the filter path.

        Show
        Raymond Auge added a comment - - Restricted to Regarding 3) I myself hate the fact that we have this naming "convention" on our various plugins (of which portlet is one). I think we should get rid of that and rely purely on descriptors. I think the solution to 1) and 2) would be to look for filters that don't have a servlet mapping, and map those to the PortletServlet. That would solve it I think. What do you think? But I'm not 100% sure why the path lookup is failing in the first place. I'd like to see the wicket code which dispatches to the filter path.
        Hide
        Thijs Vonk added a comment - - Restricted to

        The dispatching is done on line(s) 591 or line 655 of org.apache.wicket.protocol.http.portlet.WicketPortlet

        Show
        Thijs Vonk added a comment - - Restricted to The dispatching is done on line(s) 591 or line 655 of org.apache.wicket.protocol.http.portlet.WicketPortlet

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              6 years, 21 weeks, 1 day ago

              Development

                Structure Helper Panel