Bug 996064 - rich:fileUpload doesn't work in Showcase
Summary: rich:fileUpload doesn't work in Showcase
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: PortletBridge
Version: 6.1.0
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: DR01
: 6.1.1
Assignee: Nobody
QA Contact: Tomas Kyjovsky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-12 10:52 UTC by Petr Mensik
Modified: 2021-10-23 04:23 UTC (History)
5 users (show)

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.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Petr Mensik 2013-08-12 10:52:55 UTC 
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 10:54:28 UTC 
Tested with PBR 3.2.1.Final and RF 4.3.2
Comment 3 Ken Finnigan 2013-08-12 12:51:31 UTC 
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 13:04:24 UTC 
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 20:48:35 UTC 
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 12:11:38 UTC 
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 14:15:50 UTC 
Jared, can you please provide me a link for documentation so I can close this issue?
Comment 8 Ken Finnigan 2013-10-29 15:05:33 UTC 
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 10:40:43 UTC 
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.