Architectural help re behavior of Liferay servlet filters (Brian C maybe?)

[David Grigglestone, geändert vor 12 Jahren.]

Hopefully Brian Chan might take a crack at this given he wrote the InvokerFilter.

I am trying to use JBoss Errai to develop an application. Everything works cool until I try to deploy as a liferay portlet. It seems that Liferay imposes filtering on all URLs, here's just one exmaple from the web.xml:

<filter>
<filter-name>Invoker Filter - ERROR</filter-name>
<filter-class>com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter</filter-class>
<init-param>
<param-name>dispatcher</param-name>
<param-value>ERROR</param-value>
</init-param>
</filter>
...
<filter-mapping>
<filter-name>Invoker Filter - ERROR</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>ERROR</dispatcher>
</filter-mapping>

By default the Errai application will not work because Liferay cannot handle the Errai URLs .. we see messages in the Tomcat log like:
[indent][PortalImpl:4873] Current URL /web/guest/out.35231-25910.erraiBus generates exception: null[/indent]
or
[indent][PortalImpl:4873] Current URL /in.35231-25910.erraiBus generates exception: null[/indent]

In working with the JBoss Errai team they modified their code to support loading as a filter (which in their implementation does not invoke the filter chain, but their servlet directly). To make this work the Errai filter must be specified ahead of the Liferay filters and the whole application seems to require loading in ROOT. This works as long as the whole Errai application is loaded in ROOT, but clearly it would be desireable to be able to package the application in a separately deployable .war.

Are there currently any mechanisms to cause Liferay filters to ignore URLs like "*.erraiBus"?

If not, is there anyone on the Liferay development team that would be willing to work with the Errai team in order to get Errai applications deployable as portlets in Liferay?

[David H Nebinger, geändert vor 12 Jahren.]

Through the EXT plugin, you can make adjustments to the web.xml file for the ROOT web application, thus controlling your filter ordering and/or changing filter matching patterns to accommodate the Errai filter.

[David Grigglestone, geändert vor 12 Jahren.]

Thank you for your response but I don't think it answers my questions.

The first question was about driving the Liferay filters. I am already able to modify the ROOT web.xml and control the filter ordering. I'm not sure that I can/need to change Liferay filtering patterns since I think it needs to process everything ("/*").

Maybe this is driven by my confusion on my part regarding the approach I should be taking. There is the ROOT web application where Liferay imposes itself, then there are other applications (portlets) that users deploy to Liferay .. in that later case, during deployment Liferay modifies those other applications web.xml to impose Liferay (see InvokerFilter, SetPortletClassLoaderServlet & PortletServlet). For the purposes of testing I can manually modify either (a) the ROOT application web.xml or (b) my test application after Liferay has deployed in.

If I modify (a) to include the Errai filtering ahead of the Liferay filtering I am able to get my test application to work if all of the server side of the application (jars, loose classes and properties) is also placed in ROOT/WEB_INF. Clearly this is not a modular & reasonable deployment model.

If I modify (b) to include the Errai filtering ahead of the Liferay filtering I am not able to get my application working .. in the Tomcat console I see messages like:
[indent]13:03:50,227 WARN [404_jsp:?] /out.76990-225.erraiBus
13:03:50,479 WARN [404_jsp:?] /in.76990-225.erraiBus[/indent]

The second question was asking if there is anyone on the Liferay development team willing to work/communicate with the JBoss Errai team in order to help them better understand the Liferay architecture and what might be going on.

Many thanks, David