Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.0.1, EE-3.0.0.GA
-
Fix Version/s: 3.1.0.BETA1, 3.1
-
Component/s: ACE-Components, Framework
-
Labels:None
-
Environment:ICEfaces 3 ACE Portlet Portal
-
Assignee Priority:P1
Description
-
Hide
- ICE-8008.zip
- 186 kB
- Deryk Sinotte
-
- nav/.svn/all-wcprops 0.6 kB
- nav/.svn/dir-prop-base 0.0 kB
- nav/.svn/entries 0.7 kB
- nav/.svn/.../build.properties.svn-base 0.6 kB
- nav/.svn/text-base/build.xml.svn-base 1 kB
- nav/.svn/text-base/pom.xml.svn-base 1 kB
- nav/build.properties 0.6 kB
- nav/build.xml 0.9 kB
- __MACOSX/nav/._build.xml 0.2 kB
- nav/lib/.DS_Store 6 kB
- __MACOSX/nav/lib/._.DS_Store 0.1 kB
- nav/lib/.svn/all-wcprops 0.5 kB
- nav/lib/.svn/entries 0.6 kB
- nav/lib/.../jhighlight-1.0.jar.svn-base 0.1 kB
- nav/lib/.../jstl-1.1.2.jar.svn-base 0.1 kB
- nav/lib/.../jhighlight-1.0.jar.svn-base 91 kB
- nav/lib/.../jstl-1.1.2.jar.svn-base 20 kB
- nav/src/.svn/all-wcprops 0.1 kB
- nav/src/.svn/entries 0.3 kB
- nav/src/main/.svn/all-wcprops 0.1 kB
- nav/src/main/.svn/entries 0.3 kB
- nav/src/main/java/.svn/all-wcprops 0.1 kB
- nav/src/main/java/.svn/entries 0.3 kB
- nav/src/main/java/org/.svn/all-wcprops 0.1 kB
- nav/src/main/java/org/.svn/entries 0.3 kB
- nav/src/main/.../icefaces/.svn/all-wcprops 0.2 kB
- nav/src/main/java/.../icefaces/.svn/entries 0.3 kB
- nav/src/main/.../icefaces/samples/.DS_Store 6 kB
- __MACOSX/nav/src/.../samples/._.DS_Store 0.1 kB
- nav/src/main/.../samples/.svn/all-wcprops 0.2 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
This one was a bit hard to find but relatively easy to fix. It turns out that the PortletFaces Bridge was looking for a specific parameter that mapped to the current view id. The key (_facesViewId) was in the parameter map but namespaces by the portlet name. The full value would look something like this:
testNavigation_WAR_navportlet_facesViewId=%2Fpage01.xhtml
This value is stored in the map under the key "javax.faces.encodedUrl".
In the FileEntryPhaseListener, there is some wrapping of the request to do some special handling of request parameters. The same logic is done in both the servlet and portlet version of the wrapper. The method in question is:
public String getParameter(String name) {
if (parameterMap != null) {
if (!parameterMap.containsKey(name))
...
The wrapping wasn't considering the namespacing requirements that are done to portlet parameters and when the PortletFaces Bridge called getParameter to find find the value, it wouldn't find it in the map and would simply return null. What we needed to do was defer to the wrapped version of the request so that it could find the value that had already had the namespace processed.
public String getParameter(String name) {
if (parameterMap != null) {
if (!parameterMap.containsKey(name))
...
Checked in the change after testing file upload still works on portlets.
Attaching the test case. To run:
1) Download and unzip.
2) Copy the two folders (nav and nav-portlet) to icefaces/samples/showcase directory so that they can use the existing build infrastructure.
3) From the nav-portlet directory, execute: ant clean liferay6.servlet-profile
4) Copy the resulting .war file to the Liferay deploy directory (e.g. cp build/dist/*.war ~/Apps/liferay-portal-6.1.0-ce-ga1/deploy/)
5) Once deployed, create a portal page and add the portlet to the page.
To see the issue:
1) Click on the "Go to Page 2" button.
2) On the second view, choose a file and click the "Upload" button.
3) Rather than stay on the view with the fileEntry component, it goes back to the original view.