No problem, I knew this was unlikely because of its lateness, but I
thought I would try. At least I got your attention ;-). Anyway I am in
process of wrapping up jsr301 and this will soon be followed by jsr329.
This means a production 301 bridge should be released sometime in May
with a Beta 329 close behind it. The Production 329 bridge should be
out by late summer/early fall. Bug 569 only impacts the 329 bridge (and
any portlet app that has multiple portlets in it that communicate via
events). I don't recall at the moment the specific use case that caused
me to track down 581 but suspect it applies to both versions.
-Mike-
On 4/13/2010 3:07 PM, Ate Douma wrote:
On 04/13/2010 10:06 PM, Michael Freedman wrote:
-1
I would really like to see PLUTO-581 ans PLUTO-569 fixed as part of this
release. Both these bugs provide specific suggestions for code fixes.
Both these bugs have a significantly impair the JSF Bridge from
executing properly in a Pluto 2.0 environment. The second bug causes JSF
based portlets using events to deadlock. The first leads to situations
where submitted parameters are lost because they aren't properly
decoded.
-Mike-
Hi Mike,
I'm sorry to hear, this late, these issues are so important for the
JSF Portlet Bridge.
As such, I agree these issues probably should be fixed ASAP.
However, as neither of these issues were actively pursued, like with
follow up emails on the dev list after they were entered in JIRA (6
and 10 months ago), you should understand that for the Portals dev
team, as small team as we are, these issues were not recognizable as
critical to be fixed for this 2.0.1 release.
As a general rule I would suggest anyone needing specific features or
bugs fixed to actively pursue them and interact with the dev team,
more than only record them in JIRA, to ensure they'll get the proper
attention needed.
Also, I'd like to mention that for the Portals team the Pluto portlet
container is the primary target of concern, less so the Pluto Portal
Driver (which the issues you brought forward both apply to). The
Portal Driver's primary existence is providing a testbed for the
Portlet spec TCK (which the container passes), not to be a 100%
bullet-proof product for its own sake (for that you should be looking
at other, more quality driven portals like Jetspeed-2).
Having said that, these issues definitely can and should be fixed if
it helps others testing and validating, like the JSF Portlet-Bridge.
I'm willing to help out and fix these two (and more if needed) issues
ASAP, but preferably *after* the 2.0.1 release.
And if you'll need these fixes released soon, we can easily do so with
a follow up Pluto 2.0.2 release.
Please let us know your concrete time schedule and possible other
requirements are for getting these issues fixed and a possible release
to go with and we'll try to help out where we can.
Regards,
Ate
On 4/13/2010 9:14 AM, Ate Douma wrote:
Hi Pluto Team and community,
I've staged a release candidate for the new Pluto 2.0.1 release.
Please review the release candidate for this project which is
available in the following Nexus provided staging repository:
https://repository.apache.org/content/repositories/orgapacheportals-019/
The most important part is the big source archive of Pluto which is
here:
https://repository.apache.org/content/repositories/orgapacheportals-019/org/apache/portals/pluto/pluto/2.0.1/
Please also check the various maven artifacts we're deploying to the
global maven repository:
https://repository.apache.org/content/repositories/orgapacheportals-019/org/apache/portals/pluto/
In addition, I'm providing a binary Distribution (Pluto+Tomcat) based
on this release candidate here:
http://people.apache.org/~ate/releases/portals/pluto/
Please vote on releasing Apache Pluto 2.0.1
This vote is open for the next 72 hours.
Please cast your vote:
[ ] +1 for Release
[ ] 0 for Don't care
[ ] -1 Don't release (do provide a reason then)
Regards,
Ate Douma
