Jetspeed 2
  1. Jetspeed 2
  2. JS2-729

Preliminary Portlet API 2.0 ResourceURL support allowing full response control like for cookies and compressed output streams

    Details

      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.

        Activity

        Hide
        Ate Douma added a comment -

        Committed

        Show
        Ate Douma added a comment - Committed
        Hide
        Ate Douma added a comment -

        ResourceURLs need to be able to be used for POST requests too and posted form data should be available as request parameters in the portlet.
        I'll update the ServletRequestImpl which currently only allows access to POSTed parameters during processAction to also allow this for ResourceURLs (which have to be served over a JSR-168 renderRequest). This is in compliance with what JSR-286 (Portlet API 2.0) will allow for native serveResource requests.

        Show
        Ate Douma added a comment - ResourceURLs need to be able to be used for POST requests too and posted form data should be available as request parameters in the portlet. I'll update the ServletRequestImpl which currently only allows access to POSTed parameters during processAction to also allow this for ResourceURLs (which have to be served over a JSR-168 renderRequest). This is in compliance with what JSR-286 (Portlet API 2.0) will allow for native serveResource requests.
        Hide
        Ate Douma added a comment -

        ResourceURL handling from the /desktop isn't working yet.

        But just a small (internal) modification of the DesktopEncodingPortalURL and adding the resourceValve to the desktop-render-pipeline already covers most use-cases.
        I'll commit this shortly.

        What still isn't working yet is dynamic script contributions which hook onto document loading events and/or some timeout mechanism like the Wicket Lazyloading image or clock example.
        I'm not yet sure this is related to the ResourceURL generation/handling or /desktop internals (although I expect the latter).
        Steve will look into these issues after I've committed the base /desktop ResourceURL support.

        Show
        Ate Douma added a comment - ResourceURL handling from the /desktop isn't working yet. But just a small (internal) modification of the DesktopEncodingPortalURL and adding the resourceValve to the desktop-render-pipeline already covers most use-cases. I'll commit this shortly. What still isn't working yet is dynamic script contributions which hook onto document loading events and/or some timeout mechanism like the Wicket Lazyloading image or clock example. I'm not yet sure this is related to the ResourceURL generation/handling or /desktop internals (although I expect the latter). Steve will look into these issues after I've committed the base /desktop ResourceURL support.
        Hide
        Ate Douma added a comment -

        ResourceURL handling is working properly now (for a while already) since several fixes were checked in by Steve.

        Show
        Ate Douma added a comment - ResourceURL handling is working properly now (for a while already) since several fixes were checked in by Steve.

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development