portals-bridges-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shinsuke SUGAYA <shins...@yahoo.co.jp>
Subject Re: Bug in FilterPortlet
Date Sat, 16 Sep 2006 22:13:14 GMT
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


Mime
View raw message