Re: Problem with Pluto Portlets and the Sun JSF Portlets

Rather then go this route I again urge you to try the portlet via the
JSR 301 Bridge on Apache ( http://myfaces.apache.org/ ). It appears the
one you are using is the bridge in the Apache Portals project. I know
its confusing as there are actually 3 bridges on Apache -- the Apache
Portals bridge, the MyFaces 1.1 bridge and the JSR 301/MyFaces Portlet
Bridge. Its only this later that is implementing the standard being
worked on and has been community designed to work with JSF 1.2 impls.

Also, what version of the Faces RI are you running. I am not aware
that at least the impls out on Glassfish still contain bridge like
support. In particular where does com.sun.faces.portlet.LifecycleImpl
come from? It shouldn't be configured/running as
this seems to be a pretty specific portlet container bridge/faces
extension. Can you run with a JSF 1.2 version that doesn't contain
this? Or can you disable it?

-Mike-

Eric Dalquist wrote:

Just realized you attached the .java file

So the portletConfig comes from line 387:

Map requestMap = context.getExternalContext().getRequestMap();

PortletConfig portletConfig =
(PortletConfig)requestMap.get("javax.portlet.PortletConfig");

I'm wondering if that is expected as a request attribute and if so what
is supposed to set it? I do see in PLT.16.3.2 of the spec that
"javax.portlet.config" is supposed to be set as an attribute (by the
container) containing the PortletConfig when dispatching to or
including a servlet/jsp during rendering but there is no dispatch or
include in your stack trace and they would be using the wrong key.

So the question is what does the 'requestMap' represent and how does it
get populated?

-Eric

Eric Dalquist wrote:

portletConfig would have to be null to get a NPE on that line. .equals
should always be able to handle null as an argument so that wouldn't
cause the problem.

I guess the next step is to figure out how portletConfig is supposed to
get set and why it isn't.

-Eric

Domazlicky, Eric wrote:

Seems
to be this line:

if("true".equals(portletConfig.getInitParameter(BridgeConstants.CLEARING_STATE_ENABLED))
)

portletConfig
is NULL? Or maybe getInitParameter is returning
NULL (I’m fairly certain this particular init param doesn’t exist)?
I’m attaching the source file if you need to do further analysis.

From:
Eric Dalquist
[ mailto:[email protected] ]

Sent: Tuesday, August 12, 2008 10:14 AM

To: [email protected]

Subject: Re: Problem with Pluto Portlets and the Sun JSF
Portlets

It would be interesting to see what LifecycleImpl.java:353
is trying to do. Do you have a pointer to the source?

-Eric

Domazlicky, Eric wrote:

Ok
here is the latest on the issue. I resolved the last error to
be a missing library. However now I am now getting this error:

Aug
12, 2008 7:58:49 AM org.apache.catalina.core.ApplicationDispatcher
invoke

SEVERE:
Servlet.service() for servlet uPortalTest threw exception

java.lang.NullPointerException

at
com.sun.faces.portlet.LifecycleImpl.clearState(LifecycleImpl.java:353)

at com.sun.faces.portlet.LifecycleImpl.restore(LifecycleImpl.java:380)

at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:231)

at
org.apache.portals.bridges.jsf.FacesPortlet.process(FacesPortlet.java:517)

at
org.apache.portals.bridges.jsf.FacesPortlet.doView(FacesPortlet.java:323)

at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)

at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)

at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)

at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)

at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594)

at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)

at
org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167)

at
org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101)

at
org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173)

at
org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:480)

at
org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:186)

at
org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:545)

at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27)

at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

at java.util.concurrent.FutureTask.run(FutureTask.java:138)

at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:619)

This
is what leads me to the conclusion that Apache Portlet
Bridge and the Sun JSF Implementation just don’t get along. Any
other ideas?

From:
Eric Dalquist [ mailto:[email protected] ]

Sent: Wednesday, August 06, 2008 5:33 PM

To: [email protected]

Subject: Re: Problem with Pluto Portlets and the Sun JSF
Portlets

That may be a uPortal issue. One of the ways
uPortal
attempts to catch context loading problems is if content is written to
the
response object passed to Pluto when initializing a portlet window. The
Faces
bridge portlet must do this. The exception message should have included
the
content that was written out, perhaps you could include that in an
email?

-Eric

Domazlicky, Eric wrote:

Ok
I realized my error I was using the wrong portlet-class from
the Apache Portlet Bridge. I was using the GenericPortlet bridge when I
should
have been using the FacesPortlet bridge. My test Sun JSF Portlet now
gets a
totally different error that I suspect is uPortal related but maybe
it’s
Pluto??

“PortletLoadFailureException:
Content was written to
response during loading of portlet window..[].. Response Content: The
requested
resource /PlutoInvoker/TestPortlet is not available”

From:
Michael Freedman [ mailto:[email protected] ]

Sent: Wednesday, August 06, 2008 4:09 PM

To: [email protected]

Subject: Re: Problem with Pluto Portlets and the Sun JSF
Portlets

If you are using the Bridge I pointed you at
it
also has the
benefit of being Faces impl independent. It will run with the Faces
1.2
RI/Sun's Faces impl. In fact I do most of my testing with a version of
the RI.

-Mike-

Domazlicky, Eric wrote:

Well
the Apache Bridge seems to work. Unfortunately though
NetBean’s Visual Designer seems to be tied to Sun JSF’s so that
means you can’t use the Designer to design a Portlet. I can get a pure
MyFaces example portlet to work using the Apache JSF Bridge however so
at least
I can confirm that Faces can work under uPortal/PLUTO.

From:
Michael Freedman [ mailto:[email protected] ]

Sent: Wednesday, August 06, 2008 2:07 PM

To: [email protected]

Subject: Re: Problem with Pluto Portlets and the Sun JSF
Portlets

Definitely let me know if you run into any
problems running
your portlet with this bridge -- the JSR is supposed to define standard
behavior for all bridges -- but obviously there is/was alot of existing
prior
art so I am interested in seeing if/what complications occur when users
migrate
so I can determine if its an issue related to specific implementation
dependent
function in the legacy bridge or the standard's definition needs
expanding.

-Mike-

Domazlicky, Eric wrote:

Thanks
I’ll give the Apache portlet-bridge a try and see
what I can find.

From:
Michael Freedman [ mailto:[email protected] ]

Sent: Wednesday, August 06, 2008 1:47 PM

To: [email protected]

Subject: Re: Problem with Pluto Portlets and the Sun JSF
Portlets

Request and Response wrapping is not
supported
in the
Portlet 1.0 (JSR 168) standard hence the use of a request wrapper by
the Sun
JSF bridge ( it is the Sun bridge, right?) is implementation dependent
and can
only be assumed to work in a Sun portlet container. Instead, try the
JSR
301 Bridge whose (early) Reference Implementation is on Apache ( http://myfaces.apache.org/portlet-bridge/index.html ).
I would suggest getting the sources and building yourself as the last
release
was posted coincident with the last early draft earlier this year and
things have progressed a bit since then. (Though that binary release
is
also stable and fully functional for most uses). Note: this impl is
intended to be portlet container independent. It doesn't rely on
wrapping.

When you look at this Apache project you will notice there are two code
lines. The JSR is producing a spec and impl for both portlet 1.0 and
portlet 2.0 with JSF 1.2. Portlet 2.0 (JSR 286) does define wrapping,
hence its the portlet 2.0 bridge version that wanted to use wrapping
and hit
the bug referenced by Craig.

-Mike-

[email protected]
wrote:

PLUTO-478
covers this issue. It was reported by Mike Freedman, spec lead of
JSR-301, the
JSF-Portlet Bridge.

Any
fix to this issue should be done on the 1.1.x and 2.0-refactoring
branch
and the trunk.

/Craig

[email protected]
wrote:
-----

To: [email protected]

From: [email protected]

Date: 08/05/2008 07:29PM

Subject: Re: Problem with Pluto Portlets and the Sun JSF Portlets

>
I had
directed Eric over here from the uPortal lists.

>

> It appears that the JSF-Portlet library adds a response wrapper
before

> calling the request dispatcher. Does anyone here know if that is
allowed

> under JSR-168? There is no mention I can find in the spec or
errata. I

> do know in 286 explicit wrapper classes were added that mimic the

> servlet API wrapper classes but that is all I've been able to find.

> Should this be viewed as a Pluto bug or a JSF-Portlet bug?

>

> -Eric

I would expect the PortletRequestDispatcher.include() should accept any

implementation of PortletRequest/Response, but that is probably not

guaranteed by the spec. Even if this is not a Pluto bug, I wonder if a

simple fix might be to use a ThreadLocal to store the internal

request/response objects when o.a.p.core.PortletServlet passes the
request

off to the portlet, rather than using wrapper classes.

Actually, as I look at the code, I wonder if

PortletRequestDispatcherImpl.include should wrap the

PortletRequest/Response objects in adapters that implement

HttpServletRequest/Response rather than unwrap them to pull out the

internal implementation. That way, the client's wrapper classes could

still function as expected. I could put together a patch for this if
you

think it is a good idea.

-- Ben

P.S. - I'm replying to pluto-user, but I wonder if this is more

appropriate for pluto-dev?