Primefaces p:fileDownload and p:dataExporter view limitation

[Mihaly Szlauko, geändert vor 9 Jahren.]

Dear Neil!

I sended a post under FACES-1513 ticket. Meanwhile I try to create the xhtml page what I wanted to post, the components are worked. That was incredible... Finally, after a lot code analizing I found the problem. When I try to use the component on the defaultView everything was fine.
<init-param>
<name>javax.portlet.faces.defaultViewId.view</name>
<value>/views/view.xhtml</value>
</init-param>

But when I try on an other view, the client browser cannot start downloading, instead of throw me the default page without css(I think something resource fail). In this case I used this code:

<h:commandLink value="download">
<p:fileDownload value="#{exportBean.file}" />
</h:commandLink>

And log look like:
09:02:39,036 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[RESTORE_VIEW 1] viewId=[null]
09:02:39,040 DEBUG [DebugPhaseListener:48] AFTER phaseId=[RESTORE_VIEW 1] viewId=[/views/view.xhtml]
09:02:39,041 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[APPLY_REQUEST_VALUES 2] viewId=[/views/view.xhtml]
09:02:39,041 DEBUG [DebugPhaseListener:48] AFTER phaseId=[APPLY_REQUEST_VALUES 2] viewId=[/views/view.xhtml]
09:02:39,042 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[PROCESS_VALIDATIONS 3] viewId=[/views/view.xhtml]
09:02:39,042 DEBUG [DebugPhaseListener:48] AFTER phaseId=[PROCESS_VALIDATIONS 3] viewId=[/views/view.xhtml]
09:02:39,042 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[UPDATE_MODEL_VALUES 4] viewId=[/views/view.xhtml]
09:02:39,043 DEBUG [DebugPhaseListener:48] AFTER phaseId=[UPDATE_MODEL_VALUES 4] viewId=[/views/view.xhtml]
09:02:39,043 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[INVOKE_APPLICATION 5] viewId=[/views/view.xhtml]
09:02:39,045 DEBUG [DebugPhaseListener:48] AFTER phaseId=[INVOKE_APPLICATION 5] viewId=[/views/view.xhtml]


When I used below, did the same:

<p:commandLink value="download" ajax="false">
<p:fileDownload value="#{exportBean.file}" />
</p:commandLink>

Log looks like(the link was http://localhost:8080/web/guest/onkiszolgalo/-/onkiszolg/fuggvenytar?p_p_lifecycle=2&p_p_cacheability=cacheLevelPage and the view should be /views/fuggvenytar.xhtml):
09:03:30,574 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[RESTORE_VIEW 1] viewId=[null]
09:03:30,578 DEBUG [DebugPhaseListener:48] AFTER phaseId=[RESTORE_VIEW 1] viewId=[/views/view.xhtml]
09:03:30,579 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[APPLY_REQUEST_VALUES 2] viewId=[/views/view.xhtml]
09:03:30,579 DEBUG [DebugPhaseListener:48] AFTER phaseId=[APPLY_REQUEST_VALUES 2] viewId=[/views/view.xhtml]
09:03:30,580 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[PROCESS_VALIDATIONS 3] viewId=[/views/view.xhtml]
09:03:30,580 DEBUG [DebugPhaseListener:48] AFTER phaseId=[PROCESS_VALIDATIONS 3] viewId=[/views/view.xhtml]
09:03:30,580 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[UPDATE_MODEL_VALUES 4] viewId=[/views/view.xhtml]
09:03:30,581 DEBUG [DebugPhaseListener:48] AFTER phaseId=[UPDATE_MODEL_VALUES 4] viewId=[/views/view.xhtml]
09:03:30,581 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[INVOKE_APPLICATION 5] viewId=[/views/view.xhtml]
09:03:30,581 DEBUG [DebugPhaseListener:48] AFTER phaseId=[INVOKE_APPLICATION 5] viewId=[/views/view.xhtml]
09:03:30,582 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[RENDER_RESPONSE 6] viewId=[/views/view.xhtml]
09:03:30,590 DEBUG [DebugPhaseListener:48] AFTER phaseId=[RENDER_RESPONSE 6] viewId=[/views/view.xhtml]


Do you have an idea about it?

Thank you,
Mihaly

[Neil Griffin, geändert vor 9 Jahren.]

Hi Mihaly,

Thanks for reporting the problem with views other than the default view. I was able to reproduce the problem and develop a fix. When you get a chance, please download the latest version of the patch from the FACES-1513 issue and let me know if it works.

Kind Regards,

Neil

[Mihaly Szlauko, geändert vor 9 Jahren.]

Hi Neil!

I checked your latest patch with upload and download too. I noticed everything is fine.

Thank you for fast fix.

Mihaly

[Neil Griffin, geändert vor 9 Jahren.]

Hi Mihaly,

Thanks for letting us know about the good results. Your testing really helped us improve the patch!

Kind Regards,

Neil

[Christian Wilkie, geändert vor 9 Jahren.]

Great patch, I was trying to use Primefaces with Liferay today and couldn't figure out why the p:dataExporter wasn't working. After applying the patch I was able to successfully export XLS and CSV. Thanks Neil and Mihaly for opening the issue.

[Neil Griffin, geändert vor 9 Jahren.]

Thanks so much for the kind words and for reporting your feedback Christian.

That kind of feedback helps us make a determination as to whether or not the patch should move from -SNAPSHOT status to an official patch.

[Ricardo Candeias, geändert vor 9 Jahren.]

Hi,

I hope my question is in the right place first of all.

I'm also trying to use p:dataExporter and i'm getting the following MIME type related errors:

application/pdf is not a supported mime type
application/vnd.ms-excel is not a supported mime type

I tried the 3.1.4 version of the patch and i'm still getting those errors. I'm using Liferay CE 6.1 and Primefaces 5.0.

Should the patch work for those versions or the errors i'm getting aren't related to what the patch fixed?

[Neil Griffin, geändert vor 9 Jahren.]

Hi Ricardo,

I searched the PrimeFaces and Liferay Faces source code for "not a supported mime type" but I don't see any occurrences.

Do you see this error message on in the browser console or in the server log? If you see it on the server, is there a stacktrace that you can provide?

Thanks,

Neil

[Ricardo Candeias, geändert vor 9 Jahren.]

Hi Neil,

Thanks for answering.

I get the error on the server log. The stacktrace is the following for both xls and pdf when i attempt to export the contents of a p:datatable:

08:24:16,012 ERROR [http-bio-8080-exec-2][render_portlet_jsp:157] java.lang.IllegalArgumentException: application/vnd.ms-excel is not a supported mime type
at com.liferay.portlet.MimeResponseImpl.setContentType(MimeResponseImpl.java:172)
at com.liferay.faces.bridge.container.PortletContainerImpl.setMimeResponseContentType(PortletContainerImpl.java:516)
at com.liferay.faces.bridge.context.ExternalContextCompatImpl.setResponseContentType(ExternalContextCompatImpl.java:642)
at com.liferay.faces.bridge.context.IncongruityContextCompatImpl.makeCongruousJSF2(IncongruityContextCompatImpl.java:145)
at com.liferay.faces.bridge.context.IncongruityContextImpl.makeCongruous(IncongruityContextImpl.java:54)
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:222)
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:85)
at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:112)
at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:255)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:204)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103)
at com.liferay.portlet.ScriptDataPortletFilter.doFilter(ScriptDataPortletFilter.java:55)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

08:28:06,432 ERROR [http-bio-8080-exec-10][render_portlet_jsp:157] java.lang.IllegalArgumentException: application/pdf is not a supported mime type
at com.liferay.portlet.MimeResponseImpl.setContentType(MimeResponseImpl.java:172)
at com.liferay.faces.bridge.container.PortletContainerImpl.setMimeResponseContentType(PortletContainerImpl.java:516)
at com.liferay.faces.bridge.context.ExternalContextCompatImpl.setResponseContentType(ExternalContextCompatImpl.java:642)
at com.liferay.faces.bridge.context.IncongruityContextCompatImpl.makeCongruousJSF2(IncongruityContextCompatImpl.java:145)
at com.liferay.faces.bridge.context.IncongruityContextImpl.makeCongruous(IncongruityContextImpl.java:54)
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:222)
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:85)
at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:112)
at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:255)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:204)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103)
at com.liferay.portlet.ScriptDataPortletFilter.doFilter(ScriptDataPortletFilter.java:55)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

I believe i'm getting the default behaviour of p:dataExporter or p:dataDownload without the patch, from what i've read., which makes me believe that i'm not applying the 1513 patch correctly. But i followed the instructions and copied it to tomcat/webapps/myportlet/WEB-INF/lib and restarted Tomcat. Either way, i apparently got one of the workarounds working (kian's).

Thanks again,

Ricardo

[Neil Griffin, geändert vor 9 Jahren.]

Hi Ricardo,

The stacktrace indicates that the request is from a RenderURL (at the Portlet API level called a PortletURL) that is invoking the RENDER_PHASE of the portlet lifecycle. If the patch is applied correctly, then it should be a ResourceURL that invokes the RESOURCE_PHASE.

Regardless, I am glad that Kian's workaround is working for you.

Kind Regards,

Neil