Details
-
Improvement
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
2.2.0
-
None
Description
With the new Pluto container API and the upgrade process to integrate it in Jetspeed, see: JS2-871, it has become clear that we now can improve and simplify the portlet request state management enormously.
By now managing the request state separate from the request/response (wrapper) objects, we can almost completely get rid of all potential concurrency problems and drop all the specialized code dealing with that.
This requires some extensive refactoring but will in the end make the logic and management of the portlet invocations and renderjobs much more straightforward.
The following steps are planned to implement this:
- No more caching of PortletWindow instances:
For each request and for each "fragment" a new PortletWindow will be created on the fly
- Replace the portletWindowCache with a PortletDefinitionCache
In the current PortletWindow object model tree, the real model data is primarily the PortletDefinition itself and the cache is foremost used for quick access to that
The PortletEntity referenced from the PortletWindow only provides access to the PortletDefinition and its logical ID value which is (currently) equal to the window id
- Extend PortletWindow to provide access to and store all (and only) the PortletWindow specific state:
- PortletDefinition
- ContentFragment (and thereby also PortletContent)
- (request) attributes map
- implement also the Pluto PortletEntity interface (which only provides access to PortletDefinition) and have it point back to window.getPortletDefinition()
- When a PortletWindow is created (or better: when its related Fragment is determined) the fragment will provide the key (name==appName::portletName) into the portletDefinitionCache to retrieve its PortletDefinition
- Create a PortletWindow factory on the JetspeedRequestContext which keeps a map of current request PortletWindows keyed on windowId
- Store the currently invoked PortletWindow in a single (non-static) ThreadLocal on the JetspeedRequestContext to support the container interaction and callback access from dispatched portlets
- Merge the current PortletWindowRequestContext interface also into PortletWindow to support the container invocation process
Pluto container passes the PortletWindow around everywhere, so Jetspeed also will have direct access to the request/response state anywhere we're called back, without even having to go through the ThreadLocal to access it
The resulting new PortletWindow is completely thread save and thus all the current code needed to keep the request state in sync can be dropped.
Finally, by merging the PortletEntity with the PortletWindow we technically no longer need the PortletEntityImpl itself.
The PortletEntity (ID) used to needed for preferences lookup because a PortletEntity really is just that: a handle to a preferences set.
With the already completed refactoring of the portlet preferences however we already are actually storing the PortletEntity ID directly with the preferences (set) itself in the database.
Because of that, the PortletEntity object and database table actually have become redundant now, except for the current usage and reference from the PortletWindow.
The end result of all this therefore is expected to allow us to drop the PortletEntityImpl and everything tied to it from Jetspeed.
Note: the logical meaning and usage of a PortletEntity (ID) will remain of course.