Bug 996064 - rich:fileUpload doesn't work in Showcase
rich:fileUpload doesn't work in Showcase
Status: VERIFIED
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: PortletBridge (Show other bugs)
6.1.0
x86_64 Linux
unspecified Severity unspecified
: DR01
: 6.1.1
Assigned To: Ken Finnigan
Dominik Pospisil
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-12 06:52 EDT by Petr Mensik
Modified: 2016-10-30 18:59 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Using RichFaces fileUpload component on a JSF portlet that is present within a CDI-enabled WAR causes a java.lang.NumberFormatException to be thrown during the upload process. It is not possible to upload a file when CDI is enabled for a WAR that the portlet is contained within. To work-around the issue, remove beans.xml from the WAR to deactivate CDI, and remove all references to the CDI Portlet Filter from portlet.xml. It is only possible to use RichFaces fileUpload component on a portlet that is not also using CDI.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Mensik 2013-08-12 06:52:55 EDT
It seems that file is never uploaded, progress bar doesn't show anything and there is also error in the server log, root cause seems to be

Caused by: java.lang.NumberFormatException: null
	at java.lang.Long.parseLong(Long.java:404) [rt.jar:1.7.0_25]
	at java.lang.Long.parseLong(Long.java:483) [rt.jar:1.7.0_25]
	at org.richfaces.context.FileUploadFacesContextFactory.getFacesContext(FileUploadFacesContextFactory.java:129) [richfaces-components-ui-4.3.2.Final.jar:4.3.2.Final]
	at com.sun.faces.context.InjectionFacesContextFactory.getFacesContext(InjectionFacesContextFactory.java:121) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at org.jboss.portletbridge.bridge.controller.Jsf20ControllerImpl.getFacesContext(Jsf20ControllerImpl.java:621) [portletbridge-impl-3.2.1.Final-redhat-1.jar:3.2.1.Final-redhat-1]
	at org.jboss.portletbridge.bridge.controller.Jsf20ControllerImpl.renderResource(Jsf20ControllerImpl.java:278) [portletbridge-impl-3.2.1.Final-redhat-1.jar:3.2.1.Final-redhat-1]
	... 136 more



Steps to reproduce

1. Start JPP
2. Deploy Showcase portlet
3. Go to Inputs/rich:fileUpload
4. Try to deploy some image
Comment 1 Petr Mensik 2013-08-12 06:54:28 EDT
Tested with PBR 3.2.1.Final and RF 4.3.2
Comment 3 Ken Finnigan 2013-08-12 08:51:31 EDT
Is the PBR richfaces extension jar included in the showcase war?

The stacktrace looks like it isn't present.
Comment 4 Petr Mensik 2013-08-12 09:04:24 EDT
Yes, it's there, I thought that richfaces4-depchain should add it to the project

https://github.com/portletbridge/portletbridge/blob/3.2.1.Final/examples/richfaces-showcase/pom.xml#L65
Comment 5 Ken Finnigan 2013-08-12 16:48:35 EDT
Try removing the beans.xml and the references to the portlet filter from portlet.xml

I think the issue is that the CDI integration library for portlets is wrapping the portlet request into a http one, which makes the RF File Upload context factory kick in, and not the PBR one for RF.

If that fix works for you, not sure if we can do anything code related. It may need to be updated docs stating that rich:fileUpload can't be used in a CDI portlet.
Comment 6 Petr Mensik 2013-08-13 08:11:38 EDT
Ok, I can confirm that this behaviour is caused by adding CDI to the portlet so I suppose we need to just update the docs.
Comment 7 Petr Mensik 2013-09-03 10:15:50 EDT
Jared, can you please provide me a link for documentation so I can close this issue?
Comment 8 Ken Finnigan 2013-10-29 11:05:33 EDT
This is now resolved in GateIn master by GTNPORTAL-3275.

CDI Portlet Integration library was upgraded, and the new version defaults to not wrapping multipart requests in the filter, but it is also possible to revert to wrapping all requests.
Comment 9 Petr Mensik 2013-12-02 05:40:43 EST
Verified on JPP 6.1.1.DR1-prod that the updated library fixes this issue.

Note You need to log in before you can comment on or make changes to this bug.