[ 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)