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]

Reply via email to