portals-bridges-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Anderson" <portlet...@gmail.com>
Subject Re: Bug in FilterPortlet
Date Sun, 17 Sep 2006 17:16:47 GMT
> 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 <ate@douma.nu> 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: bridges-user-unsubscribe@portals.apache.org
> >>>> For additional commands, e-mail: bridges-user-help@portals.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: bridges-user-unsubscribe@portals.apache.org
> >>> For additional commands, e-mail: bridges-user-help@portals.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: bridges-user-unsubscribe@portals.apache.org
> >> For additional commands, e-mail: bridges-user-help@portals.apache.org
> >>
> >>
> >
> > --------------------------------------
> > [10th Anniversary] special auction campaign now!
> > http://pr.mail.yahoo.co.jp/auction/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: bridges-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: bridges-user-help@portals.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bridges-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: bridges-user-help@portals.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message