Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.1.2, 2.1.3
-
None
Description
While the PortletResourceURLFactoryImpl created for JS2-728 already works somewhat using a portlet-pipeline, going through the (Portlet)Aggregator limits its usability.
The problem is twofold:
- the Aggregator infrastructure is only capable of aggregating text based content (String ContentFragment.getContent()) so streaming binary output like compressed (Ajax) javascript libraries is not possible
- no API support for setting headers, cookies etc, although formally that isn't (directly) allowed by the servlet api either (for included requests what portlet invoking is based upon)
Additionally, the portlet urls for invoking a portlet pipeline as well as (possibly) encoded additional render parameters can become extremely long.
So, I'm going to provide more direct, although still preliminary, Portlet API 2.0 ResourceURL support through the NavigationalState encoding.
The solution is quite simple:
By setting a reserved parameter: JetspeedReservedParameters.PORTLET_RESOURCE_URL_REQUEST_PARAMETER on a RenderURL, the JetspeedNavigationStateCodec will recognize this as a ResourceURL.
A ResourceURL when received will result in NavigationalState.getPortletWindowOfResource() to be set, similar to .getPortletWindowOfAction().
The SessionNavigationalState (if used) will not store/synchronize any request parameters from a ResourceURL (this allows dropping the extra nav-state url parameter previously needed).
A new ResourceValveImpl, similar to the ActionValveImpl can be configured in any pipeline before an aggregating valve.
If the ResourceValveImpl detects that a ResourceURL is invoked (NavigationState.getPortletWindowOfResource() != null), it will short circuit the pipeline just as the ActionValveImpl does, and invoke the targetted portlet directly.
The directly invoked portlet will be provided with a full blown HttpServletResponse wrapper, meaning it captures all methods and besides buffering both the PrintWriter and ServletOutputStream it also keeps all cookies, headers, errors, status, contentType setting etc. until after the include (Tomcat won't allow setting any of these during an include, as per the servlet specs).
After the portlet returns, the buffered response is flushed to the real (portal) response and the pipeline is ended.
I've already tested this out with some examples for the Wicket portlet support I'm currently working on (which didn't work before because Wicket streams images and Ajax javascript libraries gzipped), and now they run perfectly.
Considering the amount of (Ajax) portlet-pipeline usage we already have in the desktop, it might be interesting to evaluate if that maybe can also be served using this solution.
It can allow big improvements in Ajax library downloading time through compression, and possibly also allow reducing the number of pipelines needed as the new ResourceValveImpl can be used in any pipeline.