Message Boards

JSR 362 vs. 286 renderParameter behavior

Ross Cohen, modified 5 Years ago.

JSR 362 vs. 286 renderParameter behavior

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
I was deploying portlet 3.0 portlets to Liferay 7.0.4, but upon access I received a method-not-found exception:
java.lang.NoSuchMethodError: javax.portlet.ActionResponse.getRenderParameters()Ljavax/portlet/MutableRenderParameters;

The only reason I suspected Portlet 3 support is that the LR 7 renderParameters had suddenly become persistant across multiple action requests.  The magically lingering renderParameters screws up our own internal API pretty badly, so  thinking to fix the 362 API change by clearing the renderParameters at the beggining of every action phase, I called response.getRenderParameters().clear()  -- at which point I get my CNFE.

So I need one of two solutions here:
1.  Turn off the Portlet 3.0 renderParameter behavior.
2.  Give me some way clearing the renderParameters (all of them, indiscriminantly) at the start of the action phase.

Thanks,
Ross
thumbnail
David H Nebinger, modified 5 Years ago.

RE: No Portal 3.0 (jsr 362) support?!

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Portlet 3 spec is expected to be supported on 7.2 and my be back ported to 7.1 (although I don't know if that will happen or not).

​​​​​​​It was definitely not going to be in 7.0.
Ross Cohen, modified 5 Years ago.

RE: No Portal 3.0 (jsr 362) support?!

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
Any ideas on how to revert renderParameter behavior back to what it was under jsr 168/286?

I have something near 50 portlets and I have no desire to fundamentally change the way they work -- or go through all the testing that would require.

Any insights would be greatly appreciated!     I suspect the title of my post was probably misleading.

Thanks,
Ross
thumbnail
David H Nebinger, modified 5 Years ago.

RE: No Portal 3.0 (jsr 362) support?!

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Sorry, Ross, not sure what the issue is that you're facing...

The render parameters are used for the render phase, but I wouldn't think you'd want to clear them in the action phase lest you remove something that was previously injected in there for a reason?

I'm not following what you're trying to describe, so that's probably why I'm off the track a bit...
Ross Cohen, modified 5 Years ago.

RE: No Portal 3.0 (jsr 362) support?!

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
Under the portlet 1/2 spec renderParams are supposed to be single-use -- they are supposed disappear after the subsequent render phase.

Here is what the newer spec says about difference between portlet 2 & 3 behavior in regards to renderParams (Version 3.0.0 final, pp 63):

Once render parameters have been set for a portlet during the action or event phase or by activating a render or action URL targeting the portlet, they remain available to the portlet until they are removed or until their values are changed. This holds true across subsequent action and event phase processing as well9.

Note the footnote, '9' :
9 Note that this differs from Version 2.0 behavior. In Version 2.0, all render parameters had to be set on the ActionResponse or EventResponse, even if they were unchanged as compared to the values during the last render phase.

If you need me to, I will find this behavior decribed in the version 2 spec also.


Thus, a renderParameter available in render phase 1 is not supposed to exist for render phase 2 -- unless it again set during the intervening action (or event) phase.

ALL our applications depend on this behavior -- a behavior explicitly and clearly set out in all versions of the spec.  

I can state with certainty that Liferay 6.1 conforms to the Portal 2.0 spec in this regard.  LR 7.0.4 does not seem to either conform to either the portal 2 or portal 3 spec.


All I really need to know:

Can I make LR 7.x behave according to the portlet 2.0 spec -- that is, can I get it to forget renderParams subsequent to the render phase (as described by the spec)?  Perhaps there is something I can set in portal-ext.properties?

Thanks!
Ross
thumbnail
David H Nebinger, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Hmm, hard to say.

I know that spec 3 support is coming in 7.2, but work has been going on for awhile now (since 7.0, iirc), so it is possible I suppose that a spec 3 variant of render request handling had worked its way in, and there would have been no reason for a spec 2 TCK to test for the negative case of render params resetting.

I don't believe there is a portal-ext.properties way of controlling spec conformance.

For your own case, I'm guessing you could use a portlet filter in front of your action and event handlers to manually purge stuff out, but that's just an off the cuff idea that I don't know if it carries water or not...
Ross Cohen, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
Here is what the 286 spec has to say on the matter of renderParams (portlet 2.0 final, p. 77):

Note that render parameters get automatically cleared if the portlet receives a
processAction or processEvent call and need to be explicitly re-set on the response of
such a lifecycle call.


The clearing of renderParams is a required behavior the 2.0 specs; it is explicitly and positively stated.   If you're going to depart from the spec, you should:
1.  warn people, and
2.  provide some kind of switch to revert to spec-compliant mode.

Some further adivce:
1.  Don't offer a partial implementation of specs;  it is confusing -- especially when that partial implementation alters established behavior.
2.  Have better test coverage.   The 2.0 spec makes 7 statements about RenderParams, and your tests had (apparently) no coverage for one of those statments.   This is an obvious and non-trivial part of how renderParams behave, and anyone who has actually used them in real life will expect it.
3.  Please remember that some organizations have large investments riding on spec conformance.   Inadvertant divergence from spec conformance does not inspire confidence.  


If anyone wants their Liferay 7.x portlets to conform to the 2.0 spec (at least in regards to render parameters), extend Porlet2ConformantPortlet (below).   It's a somewhat hacky fix, and I haven't had a chance to do much testing (use at your own peril), but it does appear to work.  

import com.liferay.portlet.PortletRequestImpl;

public class Porlet2ConformantPortlet extends GenericPortlet {

    @Override
    public void processEvent(EventRequest request, EventResponse response) throws PortletException, IOException {
        ((PortletRequestImpl) request).clearRenderParameters();
        super.processEvent(request, response);
    }

    @Override
    public void processAction(ActionRequest request, ActionResponse response) throws PortletException, IOException {
        ((PortletRequestImpl) request).clearRenderParameters();
        super.processAction(request, response);
    }
}


Your extending portlet will, of course, have to call the super methods for processAction() and processEvent(), and make this call immediately, before doing anything else.

Thanks,
Ross
thumbnail
David H Nebinger, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Ross Cohen Here is what the 286 spec has to say on the matter of renderParams (portlet 2.0 final, p. 77):

Note that render parameters get automatically cleared if the portlet receives a
processAction or processEvent call and need to be explicitly re-set on the response of
such a lifecycle call.


The clearing of renderParams is a required behavior the 2.0 specs explicitly and positively states.   If you're going to depart from the spec, you should:
1.  warn people, and
2.  provide some kind of switch to revert to spec-compliant mode.
Hey, wait a second, you've made this claim that it is not following a spec, but I haven't seen any proof of it.

Portlet 3 will be available in 7.1 GA4, but it hasn't been in any earlier release nor is it in 7.0 at all.

If you are seeing that Liferay 7.0 does not conform to the Portlet 2 spec, open a ticket on issues.liferay.com and provide some code to replicate the issue.

Until then I don't even know if there is truly a problem or not; if it is a problem, it would be a bug that should be reported.

Some further adivce:
1.  Don't offer a partial implementation of specs;  it is confusing -- especially when that partial implementation alters established behavior.
2.  Have better test coverage.   The 2.0 spec makes 7 statements about RenderParams, and your tests had (apparently) no coverage for one of those statments.   This is an obvious and non-trivial part of how renderParams behave, and anyone who has actually used them in real life will expect it.
3.  Please remember that some organizations have large investments riding on spec conformance.   Inadvertant divergence from spec conformance does not inspire confidence.
We don't offer a partial implementation, we support both the Portlet 1 and Portlet 2 specs completely and have upcoming support for Portlet 3 spec.

We verify our compliance using the TCKs. We ensure that our compliance per the TCK before stating we adhere to the spec.

It is possible that the Portlet 2 spec might not have a test in the TCK to verify this particular line item; if so, that would point to an issue w/ the Portlet 2 TCK and not necessarily Liferay's implementation and/or custom test cases.

We recognize that spec compliance is important and we're one of the last portal vendors standing. We strive to comply to the specs and trust that the TCKs, provided by the specification expert group from the JCP, are complete enough to verify compliance since, in order to state we are compliant, we must show that we can successfully pass the TCK.

If there is a non-compliance or a failed test from the TCK or even a gap in the TCK to verify a particular specification detail, this is likely a bug that needs to be reported and resolved but does not represent an intention to violate the specification.

If anyone wants their Liferay 7.x portlets to conform to the 2.0 spec (at least in regards to render parameters), extend Porlet2ConformantPortlet (below). It's a somewhat hacky fix, and I haven't had a chance to do much testing (use at your own peril), but it does appear to work.
That actually won't work for folks building portlets using established frameworks like JSF, Liferay MVC, Spring MVC, etc.

Instead you're probably better off implementing a PortletFilter per PLT.20 of the Portlet 2.0 specification. The filter can wrap portlet implementations of all types and apply the clearing that you've suggested.
Ross Cohen, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
Fair enough;  it might take me a couple days, but I'll cobble together a test case demonstrating the issue.
Sorry, if I was a bit shirty;   I do appreciate your time.

Ross
thumbnail
David H Nebinger, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Well, honestly for me the issue is what someone would think landing here from a google search wanting to know Liferay's JSR compliance...

They could easily come away thinking that Liferay wasn't compliant or did not care to comply or ...

All of these perceptions would be wrong, hence the strong pushback from my part.
​​​​​​​
Ross Cohen, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
I have made the simplest possible application which displays the JSR 286 violation -- it has only one java file and one jsp.

I've attached both the source project as a zip file, and the resultant Liferay-ready WAR.

If you want to compile or build the war from scratch you will need ant + ivy.   

To compile, type:
ant compile <enter>

To build the Liferay-ready war, type:
ant war <enter>

Also, if you want to use the deploy target, you will need to change the values in the build.properties to something useful.


Thanks,
Ross
Ross Cohen, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
Two further minor points which should have been included in my last post:
1.  Deployed, the application will appear under in the "Add" widget under "E1B"
2.  The portlet itself will display instructions for causing/displaying the violation.

Thanks,
Ross
Ross Cohen, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

New Member Posts: 12 Join Date: 1/4/12 Recent Posts
Was hoping for some kind of acknowledgement (or even repudiation) of the project/war I provided showing the Liferay 7.x  render paramater misbehavior.
Is someone going to look at this?

Ross
thumbnail
David H Nebinger, modified 5 Years ago.

RE: JSR 362 vs. 286 renderParameter behavior

Liferay Legend Posts: 14919 Join Date: 9/2/06 Recent Posts
Sorry, Ross, been busy with my day job emoticon

​​​​​​​I am still planning on checking it though, just not sure when I'll get to it...