Bug 996064 – rich:fileUpload doesn't work in Showcase

Bug 996064 - rich:fileUpload doesn't work in Showcase

Summary:	rich:fileUpload doesn't work in Showcase

Status:	VERIFIED

Aliases:	None

Product:	JBoss Enterprise Portal Platform 6
Classification:	JBoss
Component:	PortletBridge (Show other bugs)
Sub Component:
Version:	6.1.0
Hardware:	x86_64 Linux

Priority	unspecified Severity unspecified
Target Milestone:	DR01
Target Release:	6.1.1
Assigned To:	Ken Finnigan
QA Contact:	Dominik Pospisil
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2013-08-12 06:52 EDT by Petr Mensik
Modified:	2016-10-30 18:59 EDT (History)
CC List:	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)
Add an attachment (proposed patch, testcase, etc.)

Groups: 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.