portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Created: (JS2-938) Create flyweight PortletWindow instances for each request, the handle to access and store all portlet interaction data and drop the PortletEntityImpl usage
Date Fri, 20 Mar 2009 21:15:50 GMT
Create flyweight PortletWindow instances for each request, the handle to access and store all
portlet interaction data and drop the PortletEntityImpl usage 

                 Key: JS2-938
                 URL: https://issues.apache.org/jira/browse/JS2-938
             Project: Jetspeed 2
          Issue Type: Improvement
          Components: Components Core, Container, Portlet Entities and Preferences
    Affects Versions: 2.2
            Reporter: Ate Douma
            Assignee: Ate Douma
            Priority: Critical
             Fix For: 2.2

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

- 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
     - 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.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message