You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Kito Mann <km...@virtua.com> on 2009/05/27 19:47:15 UTC
[PORTLET-BRIDGE] questions about servlet path and servlet path info
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
Re: [PORTLET-BRIDGE] questions about servlet path and servlet path
info
Posted by michael freedman <mi...@oracle.com>.
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