Re: [PORTLET-BRIDGE] questions about servlet path and servlet path info

[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