Details
-
Type: Bug
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: 3.0.1
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:HideDiscovered with Liferay Faces Bridge 3.0.0-BETA1, but this is not a portlet-specific problem. It can be reproduced with the following portlet after clicking the "Submit" button:
http://www.liferay.com/community/liferay-projects/liferay-faces/demos#icefaces3-portlet
The bridge hacks around this problem by removing the bogus FacesMessage from the FacesContext. See the console log for a message like this:
17:31:36,159 WARN [BridgeNavigationHandlerImpl:115] Removed bogus FacesMessage caused by http://jira.icesoft.org/browse/ICE-7996
ShowDiscovered with Liferay Faces Bridge 3.0.0-BETA1, but this is not a portlet-specific problem. It can be reproduced with the following portlet after clicking the "Submit" button: http://www.liferay.com/community/liferay-projects/liferay-faces/demos#icefaces3-portlet The bridge hacks around this problem by removing the bogus FacesMessage from the FacesContext. See the console log for a message like this: 17:31:36,159 WARN [BridgeNavigationHandlerImpl:115] Removed bogus FacesMessage caused by http://jira.icesoft.org/browse/ICE-7996
Description
The handleNavigation(FacesContext, String, String) method has some code that looks like this:
wrapped.handleNavigation(context, fromAction, outcome);
viewRoot = context.getViewRoot();
NavigationCase navigationCase = getNavigationCase(context, fromAction, outcome);
if (navigationCase != null && !navigationCase.isRedirect()) {
viewMap = viewRoot.getViewMap();
viewMap.putAll(propagated);
if (null != oldDOM) {
viewMap.put(DOMResponseWriter.OLD_DOM, oldDOM);
}
}
The problem is that the call to getNavigationCase(context, fromAction, outcome) happens too late. It has to happen BEFORE the call to wrapped.handleNavigation(context, fromAction, outcome). The way it is now, the wrapped navigation-handler has already put a new ViewRoot in the FacesContext, and subsequent calls to getNavigationCase(...) will fail and causes a FacesMessage like this:
Unable to find matching navigation case with from-view-id '/views/bar.xhtml' for action '#{backingBean.submit}' with outcome 'success'
wrapped.handleNavigation(context, fromAction, outcome);
viewRoot = context.getViewRoot();
NavigationCase navigationCase = getNavigationCase(context, fromAction, outcome);
if (navigationCase != null && !navigationCase.isRedirect()) {
viewMap = viewRoot.getViewMap();
viewMap.putAll(propagated);
if (null != oldDOM) {
viewMap.put(DOMResponseWriter.OLD_DOM, oldDOM);
}
}
The problem is that the call to getNavigationCase(context, fromAction, outcome) happens too late. It has to happen BEFORE the call to wrapped.handleNavigation(context, fromAction, outcome). The way it is now, the wrapped navigation-handler has already put a new ViewRoot in the FacesContext, and subsequent calls to getNavigationCase(...) will fail and causes a FacesMessage like this:
Unable to find matching navigation case with from-view-id '/views/bar.xhtml' for action '#{backingBean.submit}' with outcome 'success'
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Neil Griffin
made changes -
Field | Original Value | New Value |
---|---|---|
Environment |
Discovered with Liferay Faces Bridge 3.0.0-BETA1, but this is not a portlet-specific problem. It can be reproduced with the following portlet after clicking the "Submit" button: http://www.liferay.com/community/liferay-projects/liferay-faces/demos#icefaces3-portlet |
Discovered with Liferay Faces Bridge 3.0.0-BETA1, but this is not a portlet-specific problem. It can be reproduced with the following portlet after clicking the "Submit" button: http://www.liferay.com/community/liferay-projects/liferay-faces/demos#icefaces3-portlet The bridge hacks around this problem by removing the bogus FacesMessage from the FacesContext. See the console log for a message like this: 17:31:36,159 WARN [BridgeNavigationHandlerImpl:115] Removed bogus FacesMessage caused by http://jira.icesoft.org/browse/ICE-7996 |
Salesforce Case | [] |
Neil Griffin
created issue -