Okay, what threw me off was your PortletExternalContextImpl code
reference: Maybe you are looking at the wrong sources? The source in
the zip on the project's download page for alpha 2.0.0 shows the expected:
public String getRequestServletPath()
{
// Delay computing the ViewId until someone needs it
if (mViewId == null)
{
determineView(true);
}
return mServletPath;
}
By the way, the 2.0 trunk now contains a facelets example so you might
start with that. I am not sure I have verified this example runs with
myFaces (by the way which specific MyFaces version of JSF are you
using?) and will investigate this/try this later today/tomorrow.
-Mike-
On 6/15/2010 3:24 AM, Rossen Stoyanchev wrote:
For some reason I'm not getting the messages from the user list. I've
pasted the response below for reference...
I am referencing the following Maven dependencies:
org.apache.myfaces.portlet-bridge, portlet-bridge-api, 2.0.2-alpha-2
org.apache.myfaces.portlet-bridge, portlet-bridge-impl, 2.0.2-alpha-2
I will try the code in trunk as well. I'm pretty sure I'm not using
anything related to MyFaces 1.1.
Rossen
--------------
Re: MyFaces JSF-Portlet Bridge and Facelets
Michael Freedman
Thu, 10 Jun 2010 08:06:17 -0700
What bridge are you using? It sounds like the myfaces bridge that was
included in MyFaces 1.1. The information referenced in the cited
posting concerning the provided portletFaceletViewHandler concerns the
JSR 301/329 bridges (Portlet 1.0 Bridge for JavaServer Faces 1.2 and
Portlet 2.0 Bridge for JavaServer Faces 1.2) whose RIs are developed
in as a MyFaces subproject
(http://myfaces.apache.org/portlet-bridge/index.html). This is a
completely different bridge and is designed to only run on JSF 1.2. If
you combine this bridge with a JSF 1.2 impl and the facelets jars +
the cited PortletFaceletViewHandler things should work. In fact if you
grab/build the code out of SVN there is now a facelets example that is
part of the project.
FYI ... JSR 301/this bridge as per spec no longer returns null for
getRequestServletPath but rather the computed servlet path based on
the target view and the known FacesServlet mapping.
-Mike-
--------------
Rossen Stoyanchev wrote:
Hi,
I've read the following thread:
http://www.mail-archive.com/users@myfaces.apache.org/msg55211.html
I tried using the provided implementation of
PortletFaceletViewHandler along with com.sun.facelets 1.1.14 without
success. After some though investigation I don't see how this
implementation could work.
This is the stack trace:
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.application.DefaultViewHandlerSupport.calculateFacesServletMapping(DefaultViewHandlerSupport.java:156)
at
org.apache.myfaces.application.DefaultViewHandlerSupport.getFacesServletMapping(DefaultViewHandlerSupport.java:116)
at
org.apache.myfaces.application.DefaultViewHandlerSupport.calculateViewId(DefaultViewHandlerSupport.java:48)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:504)
at
com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
at
com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
The provided PortletFaceletViewHandler implementation does not have a
restoreView() method, hence it is delegated to its parent, the
FaceletViewHandler. The NullPointerException eventually occurs when
trying to determine the FacesServletMappings. What is null is the
servletPath returned by the following method in myfaces
PortletExternalContextImpl:
public String getRequestServletPath()
{
return null; // must return null
}
I don't see how this could possibly work.
Furthermore, compare the suggested implementation to the
PortletViewHandler available in the myfaces portlet-bridge, which has
portlet-specific implementations of restoreView, createView, and others.
I'm either missing something or the original question about support
for Facelets in MyFaces' portlet-bridge still stands.
Thanks,
Rossen
