[
https://issues.apache.org/jira/browse/JS2-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reopened JS2-729:
---------------------------
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.
> 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
>
>
> 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]
