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

Ate Douma resolved JS2-729.
---------------------------

    Resolution: Fixed

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


> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to