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]