[
https://issues.apache.org/jira/browse/PLUTO-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Nicklous resolved PLUTO-602.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.0.0
fixed in Pluto implementation
> Need to encode for render only renderable portlets following event
> distribution
> -------------------------------------------------------------------------------
>
> Key: PLUTO-602
> URL: https://issues.apache.org/jira/browse/PLUTO-602
> Project: Pluto
> Issue Type: Bug
> Components: portal driver
> Affects Versions: 2.0.2
> Reporter: Michael Freedman
> Fix For: 3.0.0
>
>
> Currently Pluto distributes events to all portlets in the portal registered
> to receive the event whether they are visible/renderable or not. ( I.e.
> whether they are on the current tab or not). When doEvent() is finished and
> calls close() the portlet that received the event is encoded (merged) into
> the render url that pluto redirects to at the end of the (action/event)
> request. If you have N (where N is greater than 6 or so) portlets all that
> raise/receive the same event, each on a separate tab then each of these
> portlets breaks when its action raises the event. Apache throws an
> ArrayOutOfBounds exception as we seemingly write beyond the 8k response
> header buffer limit.
> So, the fix is that Pluto should only encode the portlet in this url if its
> in fact currently renderable/visible/on the current tabbed page.
> FYI ... my use case is running the 329 Bridge TCK which has many tens of
> event tests that each uses the same event (name). Each test is on a
> different tab/page but things still fail because of the above.
> In looking at the code this may take a little jiggering to get implemented .
> Might a I suggest that you add a second close() method to
> PortletStateAwareResponseImpl that takes a boolean indicating whether the
> portlet is renderable or not (and hence whether to encode the info in the
> render url) and then have PortletContainerImpl.doEvent() call this close with
> the appropriate value. This assumes of course that you can figure out
> whether the portlet is visible/renderable and the code here can have access
> to this information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)