Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.1
-
Component/s: Documentation, Framework
-
Labels:None
-
Environment:portal portlet
Description
However if you a number of portlets on the page and navigate away from the portal page before it's had a chance to render all the portlets, the views that have not yet been rendered (along with their request-scoped beans) will be orphaned. This is due to the fact that the server-side objects (views and request beans) are created for all the portlets but the ones that are not rendered don't get a chance to register themselves with the client bridge. This means that when the dispose-views is issued, it only includes the views that it knows about (ie the ones that have been rendered).
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The approach we are going to try is to associate views on the same page and track them together. If one view is disposed, we'll check for associated views and dispose them all. This requires an attempt to use a common identifier of some kind. Since the portlet spec/api doesn't provide direct access to this information, we'll likely need to use container specific mechanisms. As per the customer's environment, we'll first target JBoss Portal 2.7.
One use case that this does not cover is if the portal page is requested but there is enough delay (due to a long running process for example) to prevent even a single portlet from rendering but the user navigates away (for example clicking a different portal tab). In this case, it's possible for 1 or all of the portlet views/beans to be created on the server but since not a single instance of the bridge is created on the client, there will never be a dispose-views request made. In this case, each set of view+beans that was created will be orphaned. At this point, not quite sure how to avoid this.
I've committed the changes to support disposing of associated views.
The non-container specific extension point code is r19213 and is now included in core.
The container specific stuff is r19214 and checked under ossrepo/projects/portletviews.
This means that the core framework now has a non-specific extension point from which to add container specific implementations.
To specify the platform-specific logic for determining which page a portlet view is associated with, you use the following context parameter:
<context-param>
<param-name>com.icesoft.faces.portlet.associatedPageViewsImpl</param-name>
<param-value>com.icesoft.faces.webapp.http.portlet.page.JBossAssociatedPageViews</param-value>
</context-param>
The value should be a fully-qualified class name that extends the com.icesoft.faces.webapp.http.portlet.page.AssociatedPageViewsImpl.
Associating with SalesForce ticket