Kito,
In case Neil didn't get back to you directly ... the problem is
related to the fact that the Bridge RI works around a servlet dependency
in the JSF 1.2 RI (prior to the 1.2_13) in resolving the viewId by
setting the servlet include path attributes. Unfortunately, Liferay
also rights these attributes with its own internal rep (that has invoke
in it). This causes your problems. Neil has posted patches/suggested
fixes to the bridge (basically code to disable the bridge from writing
these attributes if running a version of Faces that doesn't contain this
servlet dependency) + you would need to pick up the 1.2_13 version of
Moharra. Watch this space for an official fix for PORTLETBRIDGE-77
which will be your signal I have checked a fix for the bridge into the
trunk.
-Mike-
Kito Mann wrote:
I'm testing out the latest snapshot of the 1.0 portlet bridge with
Mojarra 1.2_10 and Liferay 5.2, and I noticed some peculiar behavior
-- the app is expecting the file "invoke.jspx" regardless of which
view I've configured for GenericFacesPortlet. It turns out that
Liferay for some reason appends "/invoke" to the path when it
dispatches a request for the portlet regardless of the mode:
String path =
StringPool.SLASH + _portletConfigImpl.getPortletName() +
"/invoke";
RequestDispatcher requestDispatcher =
_portletContextImpl.getServletContext().getRequestDispatcher(
path);
HttpServletRequest request =
portletRequest.getHttpServletRequest();
HttpServletResponse response =
portletResponse.getHttpServletResponse();
...
requestDispatcher.include(request, response);
As far as I can tell, this is questionable behavior and is probably a
Liferay bug. However, it does bring up an interesting scenario for the
bridge. When Mojarra tries to determine the viewId in
RestoreViewPhase, it grabs it from the servlet path info:
public void execute(FacesContext facesContext) throws FacesException {
...
UIViewRoot viewRoot = facesContext.getViewRoot();
if (viewRoot != null) {
...
return;
}
Map requestMap =
facesContext.getExternalContext().getRequestMap();
String viewId = (String)
requestMap.get("javax.servlet.include.path_info");
if (viewId == null) {
viewId =
facesContext.getExternalContext().getRequestPathInfo();
}
if (viewId == null) {
viewId = (String)
requestMap.get("javax.servlet.include.servlet_path");
}
...
}
Since Liferay has sent along the "/invoke" path, Mojarra picks it up
from the "javax.servlet.include.path_info" attribute, so the the
bridge never has a chance to pick out the viewId itself
(PortletViewHandler.createViewHandler() uses the viewId already set
by Mojarra). Consequently, the app tries to display "/invoke.jspx".
So, the question is this: in the case where a path is specified for
the initial render by the container, should the bridge overwrite this
atribute so that Mojarra will pick the correct view, or should we
assume that the portlet container won't send a path to begin with?
From what I can tell, other bridges used with Liferay automatically
pick the default view for a particualr mode, so they ignore this path
altogether.
Thoughts?
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99 http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3
