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] Updated: (JS2-729) Preliminary Portlet API 2.0 ResourceURL support allowing full response control like for cookies and compressed output streams
Date Wed, 12 Sep 2007 11:52:32 GMT

     [ https://issues.apache.org/jira/browse/JS2-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ate Douma updated JS2-729:

    Fix Version/s: 2.2

> 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.2, 2.1.3
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.1.2, 2.1.3, 2.2
> 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