Thoughts?
I had been working on getting one of the Shale sample apps, shale-blank,
converted to work as a portlet using the jsf-bridge. The problem I
encountered was related to the jsf-bridge not working with Shales
application controller which is implemented as a servlet filter. It was
pretty straight forward to implement that functionality as a portlet filter.
This is why I needed compatability between the FilterPortlet and
ServletContextProvider.
Once I had that working I ran into a far more serious problem with
jsf-bridge which solution I suspect is non-trivial. The jsf-bridge takes a
perhaps overly simplistic approach of mapping portlet action requests to JSF
lifecycle execute method calls and portlet render requests to JSF lifecycle
render method calls. Since Shale apps (and probably many JSF applications)
require that lifecycle execute calls be made for every portlet request I
appeared to be at a dead end given my limited experience with JSF.
Fortunately for me, in my research to solve the second problem I encountered
with jsf-bridge, I discovered that MyFaces provides a MyFacesGenericPortlet
that has a solution which appears to solve the second problem via the
implementation of some code that accounts for the JSF's lifecycle execute
method not being called before JSF's lifecycle render method gets called.
This happens when a portlet render request is made. Additionally, it seems
that MyFacesGenericPortlet's implementation is also compatible with the use
of servlet filters. Hence I was able to use the MyFaces portlet
implementation "out of the box" without the need for a custom portlet filter
to get my Shale portlet working.
One problem though. If I now include the portals-bridges jar as one of my
war's libraries the faces-config.xml descriptor included with the jsf-bridge
gets automatically loaded and processed which results in an exception
(included below). Because of this you might want to consider moving
jsf-bridge into a secondary distribution jar and perhaps it might be wise to
even stop development on it as the MyFacesGenericPortlet implementation is
more likely to be able to more effectively address issues like mine since it
is more integrated into JSF.
Scott
Here's that exception I get from including portals-bridges.jar in my
WEB-INF/lib directory of my shale-blank portlet app (which leverages
MyFacesGenericPortlet) ...
javax.faces.FacesException: Unsupported context type
org.apache.pluto.internal.impl.PortletContextImpl
at
org.apache.portals.bridges.jsf.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:58)
at
org.apache.myfaces.portlet.MyFacesGenericPortlet.facesContext(MyFacesGenericPortlet.java:343)
at
org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:318)
at
org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
at
org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
at
org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:204)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at org.apache.pluto.core.PortletInvoker.invoke(PortletInvoker.java:169)
at org.apache.pluto.core.PortletInvoker.render(PortletInvoker.java:111)
at
org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:161)
at
org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:153)
at
org.apache.jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspx_meth_pluto_portlet_0(org.apache.jsp.WEB_002dINF.themes.portlet_002dskin_jsp:98)
at
org.apache.jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(org.apache.jsp.WEB_002dINF.themes.portlet_002dskin_jsp:73)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:966)
at
org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp._jspx_meth_c_forEach_2(org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp:724)
at
org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp._jspx_meth_c_otherwise_1(org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp:672)
at
org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp._jspx_meth_c_choose_1(org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp:540)
at
org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp._jspService(org.apache.jsp.WEB_002dINF.themes.pluto_002ddefault_002dtheme_jsp:155)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at
org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:135)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:613)
On 9/17/06, Ate Douma <[EMAIL PROTECTED]> wrote:
Shinsuke SUGAYA wrote:
> Ate Douma wrote:
>> I've created the following JIRA issues for this:
>> http://issues.apache.org/jira/browse/PB-46
>> http://issues.apache.org/jira/browse/PB-47
>> http://issues.apache.org/jira/browse/PB-48
>>
>> Fixes already committed, ready for review :)
>
> I understood problems :) I thought it occurred on an
> original portlet.. Anyway, thank you for fixing them!
>
> It's okay to me. Can we release it as 1.0.1? (do you
> have a release plan for Portals Bridges?) If there
> are no other issues and objections, I would like to
> release the portlet filter.
Well, there are several other bridges components in 1.0.1-dev development
which I would like to release soon too.
Definitely before, or no later than the Jetspeed-2.1 release, but their
are some pending changes for struts-bridge 1.0.1
which I want to finish first and there are several open issues for the
jsf-bridge which I didn't (and still don't) have
time to look into which should be resolved first too.
Be able to release portletfilter (or any other component) independently
from the other bridges would be preferable, but
we need to think about how to handle/manage this first.
Currently, the JIRA Bridges project is setup to track changes and versions
for *all* bridges components as one,
so releasing portletfilter 1.0.1 would imply a release for all components.
The easiest solution right now would be resolving the other open issues
first and release all components which are
already in 1.0.1-dev development version.
After the 1.0.1 release we then can discuss if/how we can release bridges
components independently in the future.
If someone has time to spare to look into the open issues for the
jsf-bridge would definitely speed this up a lot.
I'm currently in the process of moving jobs and have very little time to
spare right now, not even for helping out on
the Jetspeed-2.1 release.
Thoughts?
>
> Thanks,
> shinsuke
>
>>
>> Regards,
>>
>> Ate
>>
>> Ate Douma wrote:
>>> Shinsuke SUGAYA wrote:
>>>> Scott Anderson wrote:
>>>>> The portletConfig instance variable is used but never set. In the
>>>>> methods
>>>>> getInitParameter, getInitParameterNames, getPortletContext,
>>>>> getPortletName,
>>>>> & getResourceBundle you will get a NullPointerException if the
>>>>> Portlet being
>>>>> managed (portlet instance variable) is not an instance of
>>>>> PortletConfig.
>>>>
>>>> I do not see that issue.
>>> I just looked at the code and he's right. When the portlet managed is
>>> *not* an instance of PortletConfig, the FilterPortlet will use its
>>> own provided PortletConfig for resolving the request.
>>> But FilterPortlet doesn't save its PortletConfig in its init method,
>>> hence a NPE.
>>>
>>> After reviewing Scott's request to be able to use the FilterPortlet
>>> with ServletContextProvider (which requires the portlet, in this case
>>> FilterPortlet) to extend GenericPortlet, I think it can be easily
>>> "fixed", without introducing side-effects or new dependencies.
>>> As the FilterPortlet currently only implements Portlet and
>>> PortletConfig, which GenericPortlet does as well, simply extending
>>> GenericPortlet and calling super.init(PortletConfig) in its
>>> init(PortletConfig) method will resolve both issues.
>>>
>>> Additionally, I see the FilterPortlet contains another bug: in its
>>> destroy() method it doesn't call the managed portlet destroy() method.
>>>
>>> I will create a new JIRA issue for these issues, commit my proposed
>>> fixes to FilterPortlet and define
>>> portals.bridges.jsf.version=1.0.1-dev in project.properties.
>>>
>>> Then Scott can test if this indeed resolves his issues, and maybe you
>>> can validate this doesn't cause any side-effects for your usecases.
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>> Please provide(or file a bug) more information with a test case.
>>>>
>>>> Thanks,
>>>> shinsuke
>>>>
>>>>>
>>>>> Scott
>>>>>
>>>>
>>>> --------------------------------------
>>>> [10th Anniversary] special auction campaign now!
>>>> http://pr.mail.yahoo.co.jp/auction/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> --------------------------------------
> [10th Anniversary] special auction campaign now!
> http://pr.mail.yahoo.co.jp/auction/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
