掲示板

[RESOLVED] DisplayTag portlet not working in 6.1 on TC 7, but works TC 6

thumbnail
11年前 に Barry Rowe によって更新されました。

[RESOLVED] DisplayTag portlet not working in 6.1 on TC 7, but works TC 6

New Member 投稿: 14 参加年月日: 10/10/22 最新の投稿
We are having an issue migrating existing portlets to 6.1 EE GA1. We previously were running 6.0.11 (6.0 EE SP1).

The portlet we are deploying is a Legacy portlet that was built originally for Sun Portal. We updated the necessary files so that it would deploy properly into Liferay. This was successful for 6.0.11, and we have been running in production for several months.

The portlet makes use of the DisplayTag taglibs. Everything, including export works in 6.0.11. (Well, we have some minor logging conflicts, but nothing that prevents functionality).

When we deploy the same war file into a Tomcat 7 bundle for LR 6.1EE we get the following error when trying to export data:

Exception: javax.servlet.ServletException: javax.servlet.jsp.JspException: Exception: [.TableTag] Unable to reset response before returning exported data. You are not using an export filter. Be sure that no other jsp tags are used before display:table or refer to the displaytag documentation on how to configure the export filter (requires j2ee 1.3). org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:907)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:840)
com.liferay.portal.kernel.servlet.PageContextWrapper.handlePageException(PageContextWrapper.java:161)
org.apache.jsp.soldiersByStatus_jsp._jspService(soldiersByStatus_jsp.java:144)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
sun.reflect.GeneratedMethodAccessor265.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:54)
$Proxy461.doFilter(Unknown Source)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72)
com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:158)
com.liferay.portal.servlet.filters.gzip.GZipFilter.processFilter(GZipFilter.java:123)
com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:55)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
com.liferay.portal.kernel.servlet.PortalClassLoaderFilter.doFilter(PortalClassLoaderFilter.java:69)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
mil.army.usaac.portlet.fs90outlook.LogBackFilter.doFilter(LogBackFilter.java:45)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:206)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:108)
com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:71)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)

Everything I've read states the fix for this error is "Make sure your ResponseOverrideFilter is first in the list." I've tried ensuring the following is at the top of my web.xml for the portlet:
<filter>
<filter-name>DisplaytagResponseOverrideFilter</filter-name>
<filter-class>org.displaytag.filter.ResponseOverrideFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>DisplaytagResponseOverrideFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>

Is there any way to force this filter to be first in the overall filter chain? Or even better, is there a way to force a path to fall outside of the Liferay filter-chain and act just as a 'basic web application'?

Also, has anyone else seen this? I suspect there's some difference in the servlet 3.0 or jsp 2.2 spec that is causing the issue with the Tomcat Upgrade.
thumbnail
11年前 に Barry Rowe によって更新されました。

RE: Portlet with DisplayTag not working in 6.1 on Tomcat 7, but works on TC (回答)

New Member 投稿: 14 参加年月日: 10/10/22 最新の投稿
The issue stemmed from the portlet building less than correct export URLs for items. Essentially, the TableTagParameter.PARAMETER_EXPORTING request parameter was null for the export URL's in question, causing the ResponseOverrideFilter to ignore the request, and pass it on through the filter chain.

I was able to add this to the URL's being built to mark them as export urls:


<c:param name="6578706f7274" value="1" />

^The name attribute above is the value of TableTagParameter.PARAMETER_EXPORTING, and a value of 1 triggers the response override filter to execute.

This still doesn't explain why it worked under Servlet 2.4 containers, but not under Servlet 3. My guess is there is a more strict handling of response re-writing in Servlet 3.0 causing the original error.

TL;DR; Not a Liferay Issue. Invalid Displaytag Export URL's that no longer work under Servlet 3.0 spec.