Problem with primefaces monitorDownload

[Marcel Rovira, modificado hace 9 años.]

I have a composite view with a dialog to show a list of files that can be downloaded. When a file is dowloaded i need to close the dialog.
The problem is with p:fileDownload because stop method of monitorDownload is not fired.

Versions:
<org.primefaces.version>4.0</org.primefaces.version>
<liferay.version>6.1.2-ce-ga3</liferay.version>
<com.liferay.cdi.version>6.2.0.1</com.liferay.cdi.version>
<com.liferay.portal.version>6.1.2</com.liferay.portal.version>
<com.liferay.faces.version>3.1.4-ga5</com.liferay.faces.version>

Dialog with download files

	    <p:datatable id="fileTable" .... <p:column style="width:50px;">
		    	<p:commandbutton id="downloadFile" ajax="false" icon="icon-download" update="@form" onclick="PrimeFaces.monitorDownload(startMessage, finishMessage)">	    		
		    		<p:filedownload value="#{recruitingBackingBean.downloadTgssFile(recruitingModelBean.currentRecruitingProcess.processInstanceId, 
		    																		file.idFile, cc.attrs.callFrom,
		    																		recruitingModelBean.currentRecruitingProcess.processTasks)}" />		    		
		    	</p:commandbutton>				    	    
		        		    			
		</p:datatable>

BackingBean function to download

    public String downloadTgssFile(String processInstanceId, String idFile, String callFrom, Map<string, string> processTasks) {
        // Get file content
        FileDto fileDto = fileServiceClient.get(idFile);
        if (fileDto == null) {
            IllegalIdArgumentException exc = new IllegalIdArgumentException();
            exc.setErrorMessage(exc.getErrorMessage());
            throw exc;
        }

        // 1. get Liferay's ServletResponse
        PortletResponse portletResponse = (PortletResponse) JSFUtils.getExternalContext().getResponse();
        HttpServletResponse res = PortalUtil.getHttpServletResponse(portletResponse);
        res.setHeader("Content-Disposition", "attachment; filename=\"" + fileDto.getName() + "\"");//
        res.setHeader("Content-Transfer-Encoding", "binary");
        res.setContentType("application/octet-stream");
        res.flushBuffer();

        // 2. initialize the fileInputStream
        InputStream in = fileServiceClient.download(idFile);

        // 3. write the file into the outputStream
        OutputStream out = res.getOutputStream();
        out.write(IOUtils.toByteArray(in));
        out.close();

        // 4. return null to this method
        return null;
    }

</string,>

Javascript functions

    <script type="text/javascript">
        function startMessage() {
            alert("Download started!");
        }
        function finishMessage() {
            alert("Download finished!");
        }
    </script> 

Is this a known problem of the bridge or a primefaces problem?
Is there a workarround?

thanks in advance.

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

In order for us to determine if this is a portlet incompatibility, it would be great if you could try this as a plain webapp first and let us know if it works.

Thanks,

Neil

[Marcel Rovira, modificado hace 9 años.]

I've tried a simple jsf application and it works.
Here is my view code for the plain application

<!--?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?-->


<f:view contenttype="text/html">
   <h:head>
   </h:head>
   <h:body>
      <p:dialog modal="true" widgetvar="statusDialog" header="Status" draggable="false" closable="false" resizable="false">
         Here my download image !!!
      </p:dialog>

      <h:form id="form">
         <p:commandbutton id="downloadLink" value="Download" ajax="false" onclick="PrimeFaces.monitorDownload(start, stop)" icon="ui-icon-arrowthichk-s">
            <p:filedownload value="#{transferBacking.file}" />
         </p:commandbutton>
      </h:form>

      <script type="text/javascript">  
    function start() {  
    	alert("Download started!");
    }  
      
    function stop() {  
    	alert("Download finished!");
    }  
            </script>
   </h:body>
</f:view>

and bean code

@ManagedBean(name = "transferBacking")
public class TransferBacking {
	
    private StreamedContent file;  
    
    public TransferBacking() throws FileNotFoundException {  
        InputStream stream  = new FileInputStream("C://Users//marcel.rovira//Desktop//test.pdf");   
        file = new DefaultStreamedContent(stream, "application/pdf", "downloaded_test.pdf");  
    }  
      
    public StreamedContent getFile() {  
        return file;  
    }  
  
    public void setFile(StreamedContent file) {  
        this.file = file;  
    }
}

and here is my code for the portlet version (simplified)

<!--?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?-->


<f:view contenttype="text/html">
   <h:head>
   </h:head>
   <h:body>
      <p:dialog modal="true" widgetvar="statusDialog" header="Status" draggable="false" closable="false" resizable="false">
         Here my download image !!!
      </p:dialog>

      <h:form id="form">
         <p:commandbutton id="downloadLink" value="Download" ajax="false" onclick="PrimeFaces.monitorDownload(start, stop)" icon="ui-icon-arrowthichk-s">
            <p:filedownload value="#{transferBacking.downloadFile()}" />
         </p:commandbutton>
      </h:form>

      <script type="text/javascript">  
    function start() {  
    	alert("Download started!");
    }  
      
    function stop() {  
    	alert("Download finished!");
    }  
            </script>
   </h:body>
</f:view>

@Named
@ViewScoped
public class TransferBacking {

    public String downloadFile() throws Exception {

        // 1. get Liferay's ServletResponse
        PortletResponse portletResponse = (PortletResponse) JSFUtils.getExternalContext().getResponse();
        HttpServletResponse res = PortalUtil.getHttpServletResponse(portletResponse);
        res.setHeader("Content-Disposition", "attachment; filename=\"" + "test.pdf" + "\"");//
        res.setHeader("Content-Transfer-Encoding", "binary");
        res.setContentType("application/octet-stream");
        res.flushBuffer();

        // 2. initialize the fileInputStream
        InputStream in = new FileInputStream("C://Users//marcel.rovira//Desktop//test.pdf"); // new ByteArrayInputStream("file content..blah blah".getBytes());

        // 3. write the file into the outputStream
        OutputStream out = res.getOutputStream();
        out.write(IOUtils.toByteArray(in));
        out.close();

        // 4. return null to this method
        return null;

    }
}

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

is this a portlet incompatibility?
do you want i try anything else?

Thanks

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

Thanks for posting the source code, and I'm sorry it took so long for me to reply. I'll start researching the problem now.

Kind Regards,

Neil

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

I've completed my research and there are two portlet incompatibilities with p:fileDownload...

1) The p:commandButton component with ajax="false" is executing a full page postback using the "action" attribute of the surrounding <form> element. This causes the ACTION_PHASE of the portlet lifecycle to execute, followed by the RENDER_PHASE. The response contains an HTML document representing a portal page, rather than the downloaded file. Setting ajax="true" on the p:commandButton fixes the problem (in a sense), but the browser downloads the file to the browser cache and does not prompt the user to save the file (which is a problem).

2) The PrimeFaces FileDownloadActionListener sets a cookie named "primefaces.download" but the cookie is not detected by the client-side JavaScript in primefaces.js

You were able to overcome issue#1 with your portlet-specific transferBacking.downloadFile() method that provides a way to write the file to the response.

I was able to overcome issue#1 as well, but with a different approach. Specifically, what I did was to force the p:commandButton to submit the form with a different URL by using the binding attribute to determine the clientId of the form, and setting the action attribute of the form via JavaScript...

<h:form binding="#{formComponent}">
    <p:commandbutton value="Download" ajax="false" onclick="PrimeFaces.monitorDownload(start, stop);" icon="ui-icon-arrowthick-1-s">
        <p:filedownload value="#{transferBacking.file}" />
    </p:commandbutton>
</h:form>

<script type="text/javascript">
function start() {
	var formElement = document.getElementById('#{formComponent.clientId}');
	formElement.action = '#{transferBacking.resourceURL}';
	PF('statusDialog').show();
}
function stop() {
    PF('statusDialog').hide();
}
</script>

public class TransferBacking {
	public String getResourceURL() {
		FacesContext facesContext = FacesContext.getCurrentInstance();
		ViewHandler viewHandler = facesContext.getApplication().getViewHandler();
		ExternalContext externalContext = facesContext.getExternalContext();
		String viewId = facesContext.getViewRoot().getViewId();
		String facesActionURL = viewHandler.getActionURL(facesContext, viewId);
		String resourceURL = externalContext.encodeResourceURL(facesActionURL);
		return resourceURL;
	}
}

This made it possible to use the normal PrimeFaces way of having TransferBacking.getFile() return a StreamedResource.

But it also revealed issue#2 -- that the cookie set in the ResourceResponse is not available to JavaScript after the file comes back.

Why? I'm not exactly sure, but I have a guess. In a servlet environment, the URL that JSF would post-back to is for the same webapp context that requested the JSF page in the initial request. In a portlet environment, the ResourceURL is for a different webapp context than the RenderURL that requested the portal page. Because of the difference between the RenderURL and the ResourceURL, there might be a security issue of sorts that prevents the document.cookie attribute from being updated. I could be wrong, but that's my best guess.

In order to solve issue#1 in a clean way, the PrimeFaces p:fileDownload component would have to be refactored to use a JSF2 ResourceHandler. We have been in contact with Cagatay regarding this for p:dataExporter and he has it on the roadmap.

Unfortunately, I am not sure that issue#2 (the cookie issue) can be solved for portlets. If you have some time to research this, I'd be interested to know what you find out.

Kind Regards,

Neil

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

I just attached liferay-faces-1513-patch-SNAPSHOT.jar to FACES-1513. This patch should make it possible to use p:fileDownload and p:dataExporter in a portlet without doing any portlet-specific coding in your own code.

However, there are two limitations:

p:fileDownload - the PrimeFaces.monitorDownload(start, stop) JavaScript API still doesn't call the "stop" function due to cookie issues in a portlet environment.

p:dataExporter - unable to get type="xml" working but I tried "csv", "pdf", and "xls" and they worked fine.

Please give the patch a try and let me know if it works for you. Simply copy it to tomcat/webapps/yourportlet/WEB-INF/lib and restart Tomcat.

Thanks,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

I'm working on jBoss 6.1 EAP, is this patch valid for this enviroment?

Thanks you very much for all your work!!

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

Yes the patch should work in all environments. If you get a chance to try it, then please let me know if it works for you.

Thanks,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

when deploy the porlet with this jar in lib folder i have an error:

Caused by: java.lang.LinkageError: Failed to link org/apache/portals/bridges/struts/taglib/FormTag (Module "deployment.epsilon-liferay-portlets.war:main" from Service Module Loader)
...
Caused by: java.lang.NoClassDefFoundError: org/apache/struts/taglib/html/FormTag

I don't have apache.struts dependency in my pom.xml, is needed?

Do you know what is the problem?

Thanks.

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

The patch jar does not have any dependencies on Struts, so I am very surprised to see an error like that.

When you get a chance, please provide a list of all of the jars that are found in the JBoss deployed WAR's WEB-INF/lib folder.

Thanks,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

I can not prove exactly as you say because i have a previous problem. With the portlet deployed, if i stops and starts jboss, the portlet is not available and there is an error in liferay log.

07:12:14,573 ERROR [ServerService Thread Pool -- 94][CDIContextListener:66] javax.naming.NameNotFoundException: env/BeanManager -- service jboss.naming.context.java.module.ROOT.ROOT.env.BeanManager
javax.naming.NameNotFoundException: env/BeanManager -- service jboss.naming.context.java.module.ROOT.ROOT.env.BeanManager
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:103)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:174)
	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:122)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
	at com.liferay.portal.security.pacl.jndi.SchemeAwareContextWrapper.lookup(SchemeAwareContextWrapper.java:200)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at com.liferay.cdi.portlet.bridge.CDIContextListener.contextInitialized(CDIContextListener.java:61)
	at com.liferay.portal.kernel.servlet.SecurePluginContextListener.instantiatingListener(SecurePluginContextListener.java:347)
	at com.liferay.portal.kernel.servlet.SecurePluginContextListener.instantiatingListeners(SecurePluginContextListener.java:163)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.liferay.portal.deploy.hot.ServletContextListenerHotDeployListener.doInvokeDeploy(ServletContextListenerHotDeployListener.java:73)
	at com.liferay.portal.deploy.hot.ServletContextListenerHotDeployListener.invokeDeploy(ServletContextListenerHotDeployListener.java:37)
	at com.liferay.portal.deploy.hot.HotDeployImpl.doFireDeployEvent(HotDeployImpl.java:195)
	at com.liferay.portal.deploy.hot.HotDeployImpl.fireDeployEvent(HotDeployImpl.java:97)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.liferay.portal.security.lang.DoPrivilegedHandler.doInvoke(DoPrivilegedHandler.java:88)
	at com.liferay.portal.security.lang.DoPrivilegedHandler.invoke(DoPrivilegedHandler.java:56)
	at com.sun.proxy.$Proxy68.fireDeployEvent(Unknown Source)
	at com.liferay.portal.kernel.deploy.hot.HotDeployUtil.fireDeployEvent(HotDeployUtil.java:27)
	at com.liferay.portal.kernel.servlet.PluginContextListener.fireDeployEvent(PluginContextListener.java:164)
	at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalInit(PluginContextListener.java:154)
	at com.liferay.portal.kernel.util.BasePortalLifecycle.portalInit(BasePortalLifecycle.java:44)
	at com.liferay.portal.kernel.util.PortalLifecycleUtil.flushInits(PortalLifecycleUtil.java:48)
	at com.liferay.portal.servlet.MainServlet.initPlugins(MainServlet.java:847)
	at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:366)
	at javax.servlet.GenericServlet.init(GenericServlet.java:242)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1194)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1100)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3591)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3798)
	at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156)
	at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60)
	at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
07:12:14,585 ERROR [ServerService Thread Pool -- 94][CDIContextListener:71] Unable to get CDI bean manager

This occurs with my original portlet, without adding liferay-faces-1513-patch-3.1.4-ga5-SNAPSHOT in the lib folder.

The error commented before (Caused by: java.lang.NoClassDefFoundError: org/apache/struts/taglib/html/FormTag) occurs when copy .war file to liferay/deploy with your patch with jboss started
Have you any idea?

Thanks for your attention.

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

I have seen the "NameNotFoundException: env/BeanManager" error when CDI/Weld is not configured correctly in a portlet. Are you trying to use CDI/Weld in your JSF portlet?

Thanks,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

yes, my portlet is a cdi portlet. We follow the instrucctions to upgrade Mojarra in JBoss AS to version 2.1.21 and weld to 1.1.10 and it works ok when we deploy the portlet in a started jboss.

Thanks

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

It might be that you are encountering LPS-40959. Do you have cdi-portlet-bridge-shared-6.2.0.2.jar (the newest version as of the time of this writing) as a dependency in your project?

Kind Regards,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

Yes, I have this dependency, but my version is 6.2.0.1

Thanks,

Marcel.

[Neil Griffin, modificado hace 9 años.]

I would recommend that you upgrade to version 6.2.0.2 since that includes a fix for LPS-40959.

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

cdi-portlet-bridge-shared-6.2.0.2.jar solves the problem of "NameNotFoundException: env/BeanManager". Thank you very much!!!

Returning to the original problem, I copied liferay-faces-1513-patch-3.1.4-ga5-SNAPSHOT in the lib folder but the result is no good.
If i understand correctly, i can use the estandar way to download a file like this

public class TransferBacking {

    public StreamedContent downloadFile() throws Exception {

        InputStream stream = new FileInputStream("C://Users//marcel.rovira//Desktop//test.pdf"); 
        return new DefaultStreamedContent(stream, "application/pdf", "test.pdf");
    }
}

When use this, after start event download, page is redirected to an odd page without the original portlet look.
I added "BeforeDownload.jpg" and "AfterDownload.jpg" so you can see what happens.

The url before download is:
http://localhost:18080/es/web/guest/home?p_p_id=epsilonrecruiting_WAR_epsilonliferayportlet&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_epsilonrecruiting_WAR_epsilonliferayportlet__facesViewIdRender=%2Fviews%2Frecruiting%2FtestDownload.xhtml

and the url after dowload is:
http://localhost:18080/es/web/guest/home?p_p_id=epsilonrecruiting_WAR_epsilonliferayportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_epsilonrecruiting_WAR_epsilonliferayportlet__facesViewIdRender=%2Fviews%2Frecruiting%2FtestDownload.xhtml

What am I doing wrong?

Kind regards.

Marcel.

[Neil Griffin, modificado hace 9 años.]

The fact that the second URL has p_p_lifecyle=2 is very good -- that indicates the RESOURCE_PHASE of the portlet lifecycle and that the patch is working.

I would recommend that you put a System.err.println in your TransferBacking.downloadFile() method, and also surround the code in that method with a try/catch block to see if an exception is thrown. It might be the case that your double forward slashes (//) are not necessary.

Also, for best security, it is probably best to limit the resource downloading to the webapp context, using the PortletContext like this:

InputStream stream = ((PortletContext)FacesContext.getCurrentInstance().getExternalContext().getContext()).getResourceAsStream("/resources/test.pdf");
file = new DefaultStreamedContent(stream, "application/pdf", "my-test-filename.pdf");

Kind Regards,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

using PortletContext with a try catch as you said the same behavior occurs.
I verified the liferay log, jboss log and jboss console and there is no error.
This behavior occurs even without using monitordownload.

Kind regards.

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

Did you put a System.err.println in your TransferBacking.downloadFile() method? Is the method getting called?

Thanks,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

you're right, the method is not called with patch in lib folder. I have checked with System.err.println, log and debug from eclipse.
If i remove the jar and jboss restart, is called correctly

Kind regards.

Marcel.

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

When a managed-bean method is not called in a JSF application, I find that the best way to debug the problem is to add a phase-listener to the src/main/webapp/WEB-INF/faces-config.xml descriptor that will output the JSF lifecycle:

<lifecycle>
	<phase-listener>com.liferay.faces.util.lifecycle.DebugPhaseListener</phase-listener>
</lifecycle>

Note that you would also need to add the following to src/main/resources/log4j.properties:

log4j.rootLogger=INFO, R 
log4j.appender.R=org.apache.log4j.ConsoleAppender 
log4j.appender.R.layout=org.apache.log4j.PatternLayout 
log4j.appender.R.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}:%L] %m%n
log4j.logger.com.liferay.faces.util.lifecycle.DebugPhaseListener=DEBUG

And on JBoss, you need to make sure that the log4j.jar dependency is added to your pom.xml descriptor:

<dependencies>
	<dependency>
		<groupid>log4j</groupid>
		<artifactid>log4j</artifactid>
		<version>1.2.14</version>
	</dependency>
</dependencies>

When you add the patch for FACES-1513, the p:fileDownload component submits a form with a portlet ResourceURL via HTTP POST. This should cause the entire JSF lifecycle to run: RESTORE_VIEW, APPLY_REQUEST_VALUES, PROCESS_VALIDATIONS, UPDATE_MODEL_VALUES, INVOKE_APPLICATION, RENDER_RESPONSE.

My best guess is that the entire JSF lifecycle is not executing for your application. It might be that there is some type of form validation failure that is causing the UPDATE_MODEL_VALUES and INVOKE_APPLICATION phases to get skipped.

Kind Regards,

Neil

[Marcel Rovira, modificado hace 9 años.]

Hi Neil,

this is the entire log listed in jboss after following the steps you mention when clicking download button

06:26:27,517 INFO  [stdout] (http-/0.0.0.0:18080-1) 06:26:27,516 DEBUG [BridgePhaseResourceImpl:134] ----------------------------------------------------------------------
06:26:32,558 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,557 DEBUG [BridgePhaseResourceImpl:51] ----------------------------------------------------------------------
06:26:32,559 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,558 DEBUG [BridgePhaseResourceImpl:52] execute(ResourceRequest, ResourceResponse) portletName=[epsilonrecruiting]
06:26:32,559 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,559 DEBUG [PortletContainerLiferayImpl:119] Detected Liferay build number 6102
06:26:32,560 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,559 DEBUG [PortletContainerLiferayImpl:168] User-Agent requested URL=[http://localhost:18080/es/web/guest/home?p_p_id=epsilonrecruiting_WAR_epsilonliferayportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=2&p_p_col_pos=1&_epsilonrecruiting_WAR_epsilonliferayportlet__facesViewIdRender=%2Fviews%2Frecruiting%2FtestDownload.xhtml]
06:26:32,561 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,561 DEBUG [RequestHeaderMap:45] Adding content-type=[L[Content-Type: application/x-www-form-urlencoded; charset=UTF-8]] to header map
06:26:32,562 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,561 DEBUG [RequestHeaderMap:45] Adding javax.portlet.markup.head.element.support=[L[true]] to header map
06:26:32,562 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,562 DEBUG [RequestHeaderMap:45] Adding accept=[L[text/html]] to header map
06:26:32,563 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,562 DEBUG [RequestHeaderMap:45] Adding user-agent=[L[Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36]] to header map
06:26:32,565 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,564 DEBUG [BridgePhaseResourceImpl:92] Detected Non-Ajax ResourceRequest
06:26:32,565 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,565 DEBUG [BridgePhaseResourceImpl:97] Running Faces lifecycle for viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,566 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,566 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[RESTORE_VIEW 1] viewId=[null]
06:26:32,567 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,567 DEBUG [ViewHandlerImpl:84] Restoring view for viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,568 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,567 DEBUG [ViewHandlerImpl:55] Creating view for viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,578 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,577 INFO  [http-/0.0.0.0:18080-6][EpsilonModelBean:51] init()
06:26:32,580 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,579 INFO  [http-/0.0.0.0:18080-6][EpsilonModelBean:45] getMenuRecruitingItems()
06:26:32,580 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,580 INFO  [http-/0.0.0.0:18080-6][EpsilonModelBean:45] getMenuRecruitingItems()
06:26:32,581 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,581 DEBUG [DebugPhaseListener:48] AFTER phaseId=[RESTORE_VIEW 1] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,582 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,581 DEBUG [HeadPhaseListener:154] Before APPLY_REQUEST_VALUES: viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,583 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,582 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[APPLY_REQUEST_VALUES 2] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,583 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,583 INFO  [http-/0.0.0.0:18080-6][EpsilonModelBean:45] getMenuRecruitingItems()
06:26:32,584 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,584 DEBUG [DebugPhaseListener:48] AFTER phaseId=[APPLY_REQUEST_VALUES 2] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,585 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,584 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[PROCESS_VALIDATIONS 3] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,586 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,585 DEBUG [DebugPhaseListener:48] AFTER phaseId=[PROCESS_VALIDATIONS 3] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,587 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,586 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[UPDATE_MODEL_VALUES 4] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,588 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,587 DEBUG [DebugPhaseListener:48] AFTER phaseId=[UPDATE_MODEL_VALUES 4] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,588 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,588 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[INVOKE_APPLICATION 5] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,589 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,588 DEBUG [DebugPhaseListener:48] AFTER phaseId=[INVOKE_APPLICATION 5] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,590 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,589 DEBUG [HeadPhaseListener:64] After INVOKE_APPLICATION: viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,590 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,590 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[RENDER_RESPONSE 6] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,594 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,593 DEBUG [ResourceImpl:309] Removed extension=[.xhtml] from requestPath=[/epsilon-liferay-portlet/javax.faces.resource/jquery/jquery-plugins.js?ln=primefaces]
06:26:32,595 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,595 DEBUG [PortletContainerImpl:193] createResourceURL fromURL=[/epsilon-liferay-portlet/javax.faces.resource/jquery/jquery-plugins.js?ln=primefaces]
06:26:32,597 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,596 DEBUG [PortletContainerImpl:228] Added parameter to portletURL name=[javax.faces.resource] value=[jquery/jquery-plugins.js]
06:26:32,597 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,597 DEBUG [PortletContainerImpl:369] Copied parameter to portletURL name=[ln] value=[primefaces]
06:26:32,598 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,598 DEBUG [HeadResponseWriterLiferayImpl:101] Added resource to Liferay's ... section, element=[<script src="http://localhost:18080/es/web/guest/home?p_p_id=epsilonrecruiting_WAR_epsilonliferayportlet&amp;p_p_lifecycle=2&amp;p_p_state=normal&amp;p_p_mode=view&amp;p_p_cacheability=cacheLevelPage&amp;p_p_col_id=column-1&amp;p_p_col_count=2&amp;p_p_col_pos=1&amp;_epsilonrecruiting_WAR_epsilonliferayportlet_javax.faces.resource=jquery%2Fjquery-plugins.js&amp;_epsilonrecruiting_WAR_epsilonliferayportlet_ln=primefaces&amp;v=4.0" type="text/javascript"></script>]
06:26:32,599 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,598 DEBUG [ResourceRendererBridgeImpl:124] Marking resource resourceId=[primefaces:jquery/jquery-plugins.js] as being present in the head
06:26:32,602 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,601 DEBUG [ResourceImpl:309] Removed extension=[.xhtml] from requestPath=[/epsilon-liferay-portlet/javax.faces.resource/primefacesLocales.js?ln=js]
06:26:32,602 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,602 DEBUG [PortletContainerImpl:193] createResourceURL fromURL=[/epsilon-liferay-portlet/javax.faces.resource/primefacesLocales.js?ln=js]
06:26:32,603 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,603 DEBUG [PortletContainerImpl:228] Added parameter to portletURL name=[javax.faces.resource] value=[primefacesLocales.js]
06:26:32,604 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,603 DEBUG [PortletContainerImpl:369] Copied parameter to portletURL name=[ln] value=[js]
06:26:32,605 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,604 DEBUG [PortletContainerImpl:98] createActionURL fromURL=[/epsilon-liferay-portlet/views/recruiting/indexRecruiting.xhtml?_facesViewIdRender=/views/recruiting/indexRecruiting.xhtml]
06:26:32,606 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,606 DEBUG [PortletContainerImpl:369] Copied parameter to portletURL name=[_facesViewIdRender] value=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,608 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,607 DEBUG [PortletContainerImpl:98] createActionURL fromURL=[/epsilon-liferay-portlet/views/recruiting/indexRecruiting.xhtml?_facesViewIdRender=/views/recruiting/indexRecruiting.xhtml]
06:26:32,608 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,608 DEBUG [PortletContainerImpl:369] Copied parameter to portletURL name=[_facesViewIdRender] value=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,609 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,609 DEBUG [PortletContainerImpl:113] createPartialActionURL fromURL=[/epsilon-liferay-portlet/views/recruiting/indexRecruiting.xhtml?_jsfBridgeAjax=true&amp;_facesViewIdResource=/views/recruiting/indexRecruiting.xhtml]
06:26:32,610 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,609 DEBUG [PortletContainerImpl:193] createResourceURL fromURL=[/epsilon-liferay-portlet/views/recruiting/indexRecruiting.xhtml?_jsfBridgeAjax=true&amp;_facesViewIdResource=/views/recruiting/indexRecruiting.xhtml]
06:26:32,611 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,610 DEBUG [PortletContainerImpl:369] Copied parameter to portletURL name=[_jsfBridgeAjax] value=[true]
06:26:32,611 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,611 DEBUG [PortletContainerImpl:369] Copied parameter to portletURL name=[_facesViewIdResource] value=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,663 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,662 INFO  [http-/0.0.0.0:18080-6][EpsilonModelBean:45] getMenuRecruitingItems()
06:26:32,665 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,664 DEBUG [PortletContainerImpl:172] createRenderURL fromURL=[/epsilon-liferay-portlet/views/recruiting/recruitings.xhtml]
06:26:32,667 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,666 DEBUG [PortletContainerImpl:172] createRenderURL fromURL=[/epsilon-liferay-portlet/views/recruiting/indexRecruitingAdmin.xhtml]
06:26:32,669 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,668 DEBUG [PortletContainerImpl:172] createRenderURL fromURL=[/epsilon-liferay-portlet/views/recruiting/testDownload.xhtml]
06:26:32,671 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,670 INFO  [http-/0.0.0.0:18080-6][EpsilonModelBean:45] getMenuRecruitingItems()
06:26:32,672 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,672 DEBUG [DebugPhaseListener:48] AFTER phaseId=[RENDER_RESPONSE 6] viewId=[/views/recruiting/indexRecruiting.xhtml]
06:26:32,673 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,673 DEBUG [BeanManagerMojarraImpl:80] Calling invokePreDestroy for injectionProvider=[org.jboss.as.jsf.injection.JSFInjectionProvider@587849bc] managedBean=[es.gc.epsilon.core.liferay.util.JSFUtils@4aacda50]
06:26:32,674 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,674 DEBUG [BridgePhaseResourceImpl:134] ----------------------------------------------------------------------
06:26:32,695 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,693 DEBUG [BridgePhaseResourceImpl:51] ----------------------------------------------------------------------
06:26:32,696 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,695 DEBUG [BridgePhaseResourceImpl:52] execute(ResourceRequest, ResourceResponse) portletName=[epsilonrecruiting]
06:26:32,697 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,696 DEBUG [PortletContainerLiferayImpl:119] Detected Liferay build number 6102
06:26:32,699 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,698 DEBUG [PortletContainerLiferayImpl:168] User-Agent requested URL=[http://localhost:18080/es/web/guest/home?p_p_id=epsilonrecruiting_WAR_epsilonliferayportlet&amp;p_p_lifecycle=2&amp;p_p_state=normal&amp;p_p_mode=view&amp;p_p_cacheability=cacheLevelPage&amp;p_p_col_id=column-1&amp;p_p_col_count=2&amp;p_p_col_pos=1&amp;_epsilonrecruiting_WAR_epsilonliferayportlet_javax.faces.resource=primefacesLocales.js&amp;_epsilonrecruiting_WAR_epsilonliferayportlet_ln=js]
06:26:32,701 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,700 DEBUG [RequestHeaderMap:45] Adding content-type=[L[Content-Type: null; charset=UTF-8]] to header map
06:26:32,702 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,701 DEBUG [RequestHeaderMap:45] Adding javax.portlet.markup.head.element.support=[L[true]] to header map
06:26:32,703 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,702 DEBUG [RequestHeaderMap:45] Adding accept=[L[text/html]] to header map
06:26:32,704 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,703 DEBUG [RequestHeaderMap:45] Adding user-agent=[L[Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36]] to header map
06:26:32,706 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,705 DEBUG [BridgePhaseResourceImpl:62] Detected JSF2 resource request
06:26:32,709 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,708 DEBUG [ResourceImpl:234] resourceName=[primefacesLocales.js] needsUpdate=[true]
06:26:32,710 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,709 DEBUG [ResourceImpl:234] resourceName=[primefacesLocales.js] needsUpdate=[true]
06:26:32,712 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,711 DEBUG [BridgePhaseResourceImpl:134] ----------------------------------------------------------------------

I see no error, it is useful to detect something?

thanks.

Marcel

[Neil Griffin, modificado hace 9 años.]

Hi Marcel,

The following lines from the log indicate that the patch is working, because the portlet RESOUCE_PHASE is being executed:

406:26:32,559 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,558 DEBUG [BridgePhaseResourceImpl:52] execute(ResourceRequest, ResourceResponse) portletName=[epsilonrecruiting]
1106:26:32,565 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,564 DEBUG [BridgePhaseResourceImpl:92] Detected Non-Ajax ResourceRequest

The log also indicates that the entire JSF lifecycle is executing, which is good. The problem seems to be that the PrimeFaces listeners are not executing in the INVOKE_APPLICATION phase. We should be seeing the System.err.println in your TransferBacking.downloadFile() method in between the following lines:

2806:26:32,588 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,588 DEBUG [DebugPhaseListener:64] BEFORE phaseId=[INVOKE_APPLICATION 5] viewId=[/views/recruiting/indexRecruiting.xhtml]
2906:26:32,589 INFO  [stdout] (http-/0.0.0.0:18080-6) 06:26:32,588 DEBUG [DebugPhaseListener:48] AFTER phaseId=[INVOKE_APPLICATION 5] viewId=[/views/recruiting/indexRecruiting.xhtml]

If you have p:fileDownload inside of p:commandButton, then the PrimeFaces CommandButtonRenderer.decode method should be queuing an ActionEvent.

I would recommend that you download the source for PrimeFaces and Mojarra and debug the aforementioned decode method and verify that the ActionEvent is being queued. If it is, then debug the Mojarra UIViewRoot.broadcastEvents method. When the ActionEvent is broadcast, it should invoke the PrimeFaces FileDownloadActionListener.processAction method, which should result in your TransferBacking.downloadFile() method getting called.

Kind Regards,

Neil

[nacho -, modificado hace 9 años.]

Hi,
When i try to deploy my portlet with liferay-faces-1513-patch-3.1.4-ga5 on glassfish, log me back:

Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.fces.config.ConfigurationException: java.util.concurrent.ExecutionException: com.sun.faces.config.ConfigurationException: Unable to parse document 'jar:file:/opt/Liferay/glassfish-3.1.2/domains/domain/autodeploy/CRView-1.2/WEB-INF/lib/liferay-faces-1513-patch-3.1.4-ga5.jar!/META-INF/faces-config.xml': null
09-07-2014 10:50:10,577 [AutoDeploy] Autodeploy failed : /opt/Liferay/glassfish-3.1.2/domains/domain1/autodeploy/CRView-1.2.
09-07-2014 10:50:10,817 [AutoDeploy] Selecting file /opt/Liferay/glassfish-3.1.2/domains/domain1/autodeploy/CRView-1.2 for autodeployment.
09-07-2014 10:50:13,391 Initializing Mojarra 2.1.21 ( 20130409-1421 https://svn.java.net/svn/mojarra~svn/tags/2.1.21@11854) for context '/CRView-1.2'
09-07-2014 10:50:13,479 Critical error during deployment:
com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: com.sun.faces.config.ConfigurationException: Unable to parse document 'jar:file:/opt/Liferay/glassfish-3.1.2/domans/domain1/autodeploy/CRView-1.2/WEB-INF/lib/liferay-faces-1513-patch-3.1.4-ga5.jar!/META-INF/faces-config.xml': null
        at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:670)
        at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:323)
        at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216)
        at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
        at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)

the portlet carry :
…
jboss-el-2.0.0.GA.jar
jsf-api-2.1.21.jar
jsf-impl-2.1.21.jar
liferay-faces-bridge-api-3.1.4-ga5.jar
liferay-faces-bridge-impl-3.1.4-ga5.jar
liferay-faces-portal-3.1.4-ga5.jar
liferay-faces-util-3.1.4-ga5.jar
liferay-faces-1513-patch-3.1.4-ga5
…

on Liferay 6.1.1 CE GA2 and Glassfish 3.1.2


Could you please provide help me?

[Neil Griffin, modificado hace 9 años.]

Thanks for testing the patch and for bringing this problem to our attention. We accidentally had "2.2" as the version number in the faces-config.xml file when it should have been "2.1". I just attached a new version of the jar to the FACES-1513 issue. When you get a chance, please try the new version and let me know if it works. Thanks again.

[nacho -, modificado hace 9 años.]

With the new version of the patch, the portlet to deploy correctly.

I'm testing p:dataExporter. Something like this :

• XLS: OK
• PDF: OK

Thank you very much,

[Neil Griffin, modificado hace 9 años.]

It was my pleasure to help, and I'm glad to hear that it is working for you now. Thanks again for trying the patch

[Kyle Joseph Stiemann, modificado hace 8 años.]

Please do not resurrect dead threads. The new thread can be found at https://www.liferay.com/community/forums/-/message_boards/view_message/59351990.

[William Gosse, modificado hace 9 años.]

I think I'm having a similar issue with the Primefaces p:fileDownload. I guess I'm not following what the actual fix is here. I have liferay-faces-1513-patch-3.2.4-ga5-SNAPSHOT.jar in place and using the Primefaces p:dataExporter works fine for down loading datatables as xls and csv files.

However when I call the p:fileDownload my whole UI loses it theme just like another Marcel had described.

What am I missing here?

I should also mention that I'm using Primefaces 5.1.

[Kyle Joseph Stiemann, modificado hace 9 años.]

Hi William,
This sounds like an issue which is caused by having another UICommand component in the same form as the p:fileDownload/p:dataExporter components. Please make sure that those components are in their own form (See this comment on FACES-1513 for more details).

- Kyle

[William Gosse, modificado hace 9 años.]

Forget I said anything. Sometimes I think I am blind. This was total pilot error on my part because I was calling a nonexistent mbean.. Darn cut and paste! Soon as I fixed that the code worked as expected. Thanks for your reply.

[Kyle Joseph Stiemann, modificado hace 9 años.]

No problem William. Thanks for using Liferay Faces!

- Kyle