You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-user@portals.apache.org by Scott Anderson <po...@gmail.com> on 2006/09/16 05:17:40 UTC
Bug in FilterPortlet
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.
Scott
Re: Bug in FilterPortlet
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
Thank you for explaining the current status.
Okay, I wait other component release.
If I have time(probably after next week..),
I'll check bugs.
Thanks,
shinsuke
Ate Douma 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
>
>
--------------------------------------
[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
Re: Bug in FilterPortlet
Posted by David Sean Taylor <da...@bluesunrise.com>.
Ate Douma wrote:
>
> 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?
>
Ate, I'll take a look at the JSF Bridge and My Faces over the next few days.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-user-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-user-help@portals.apache.org
Re: Bug in FilterPortlet
Posted by Scott Anderson <po...@gmail.com>.
> 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 <at...@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
>
>
Re: Bug in FilterPortlet
Posted by Ate Douma <at...@douma.nu>.
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
Re: Bug in FilterPortlet
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
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.
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
Re: Bug in FilterPortlet
Posted by Ate Douma <at...@douma.nu>.
Scott Anderson wrote:
> Thanks Ate! I have tested the updated FilterPortlet and your fixes have
> resolved my issues.
Great!
I'll close the JIRA issues.
>
> Scott
>
> On 9/16/06, Ate Douma <at...@douma.nu> 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 :)
>>
>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-user-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-user-help@portals.apache.org
Re: Bug in FilterPortlet
Posted by Scott Anderson <po...@gmail.com>.
Thanks Ate! I have tested the updated FilterPortlet and your fixes have
resolved my issues.
Scott
On 9/16/06, Ate Douma <at...@douma.nu> 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 :)
>
> 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
>
>
Re: Bug in FilterPortlet
Posted by Ate Douma <at...@douma.nu>.
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 :)
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
Re: Bug in FilterPortlet
Posted by Ate Douma <at...@douma.nu>.
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
Re: Bug in FilterPortlet
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
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.
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