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 Sat, 16 Sep 2006 19:04:13 GMT
Thanks Ate! I have tested the updated FilterPortlet and your fixes have
resolved my issues.

Scott

On 9/16/06, Ate Douma <ate@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
>
>

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