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

• Type: Bug
• Status: Closed
• Priority: Major
• 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 ; ;

  LPS-25841	Primary key can not be set as "String" if relationship defined between 2 entities
  LPS-8396	Backend to support relationships between assets
  LPS-7461	Service Builder error when create the relationship between 2 entities
  LPS-6524	Realtion ship between User_ and Contact_ table
  LPS-1350	_SQL_GET clauses problem when there is One-to-Many relationship between entities.

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)

[Ivan Cheung]

Use the attached Wicket Example portlet to reproduce the error.

DO NOT use the Liferay 5.2 bundle..you must use 5.2 branch revision 25818.

Run Liferay with suns portlet-container, deploy the portlet. Now clicking the "add 1 to counter" link will increment the counter by 1 as it should.

Run this in Liferay 5.2.0 with the internal portlet-container and clicking "add 1 to counter" won't have effect.
In the right lower corner is a "Wicket Ajax Debug" link this shows debug information on the Ajax request. Here a message will show:

"The requested resource (/example-noerror-1.0-SNAPSHOT/examplenoerror/) is not available".
ERROR: Error while parsing response: Could not find root <ajax-response> element

[Sauli Ketola]

I've also been trying to get wicket to work with Liferay 5.2. without success. I tried to add this fix my configuration by setting the filter url-mapping to be identicat with portlet-name based on the instructions here. However I got an error on the portlet "The requested resource (/wicket-examples-1.4-rc2/linkomatic/invoke) is not available". Then I tried to change serlvlet url-pattern to be identical as well, but that resulted in an endless loop in the server.

[Sauli Ketola]

..it anyway seems that someone has wicket and liferay 5.2 running. I would like to know how the servlet configuration has to be done to achieve this? Also why is it important not to use the bundle but an exact revision of 5.2.

I'm using wicket-1.4-rc2, Liferay 5.2.1 (bundled with tomcat 6)

[Antony Stubbs]

Life ray was removing the '-' form my portlet name when generating it's internal servlet mapping, causing me to get this error i think.

Manually renaming everything to also remove the dash, caused me to also get this endless loop of exceptions

javax.servlet.ServletException: javax.servlet.ServletException: javax.servlet.ServletException: Servlet execution threw an exception
	at com.liferay.portlet.PortletRequestDispatcherImpl.dispatch(PortletRequestDispatcherImpl.java:313)
	at com.liferay.portlet.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:107)
	at org.apache.wicket.protocol.http.portlet.WicketPortlet.processNonActionRequest(WicketPortlet.java:752)

	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:497)
	at com.liferay.portlet.PortletRequestDispatcherImpl.dispatch(PortletRequestDispatcherImpl.java:302)
	... 382 more
ERROR - [contentadmin]             - Servlet.service() for servlet contentadmin threw exception
java.lang.StackOverflowError
	at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
	at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
	at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)

etc.

I will try now with the 5.2 branch from svn.

[Sauli Ketola]

I got past this endless-loop thing by adding <dispatcher>FORWARD</dispatcher> to the filter-mapping.
It is actually mentioned in the issue description. But I was somehow so sure that the problem was in the the servlet part that I did not notice it first.

[Wilfred Springer]

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

[Raymond Auge]

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).

[Antony Stubbs]

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"

[Raymond Auge]

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.

[Thijs Vonk]

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