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-729) Preliminary Portlet API 2.0 ResourceURL support allowing full response control like for cookies and compressed output streams
Date Mon, 04 Jun 2007 00:51:15 GMT
Preliminary Portlet API 2.0 ResourceURL support allowing full response control like for cookies
and compressed output streams

                 Key: JS2-729
                 URL: https://issues.apache.org/jira/browse/JS2-729
             Project: Jetspeed 2
          Issue Type: New Feature
          Components: Aggregation, Components Core, Container
    Affects Versions: 2.1.1
            Reporter: Ate Douma
            Assignee: Ate Douma
             Fix For: 2.1.1

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.

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