PortletSession is null when using Spring instead of Generic Portlet [SPR-3905]

[spring-projects-issues]

Michal Capo opened SPR-3905 and commented

When I use Spring Portlet support for developing portlets I get got this problem:

(handleAction) request.getPortletSession().setAttribute("a", "a", PortletSession.APPLICATION_SCOPE); (handleRender in the same portlet) String a = request.getPortletSession().getAttribute("a", PortletSession.APPLICATION_SCOPE); (variable 'a' is null)

I have attached a little test portal. You can run it by following this steps:

1. unzip this file
2. run 'mvn eclipse:eclipse' (or your other favorit IDE)
3. run/debug file 'src/main/java/org/apache/pluto/test/test1/TestPortal.java' (within Eclipse)
4. open you favorite browser and go to 'http://localhost:8080/test1/test-portal/index.jsp' OK I know this is not simply... but you can debug portlets if you want

Problem:

• click on the first 'click me' link -> everything is ok
• now click on the second one 'click me' -> hups is ok
• restart TestPortal
• click on the second 'click me' link and you got exception

---

Affects: 2.0.6

Attachments:

• test1.zip (18.52 kB)
• test1a.zip (6.99 kB)

[spring-projects-issues]

Michal Capo commented

Maven project for test

[spring-projects-issues]

Michal Capo commented

I forgot. When you change web.xml file you have to run 'mvn org.apache.pluto:maven-pluto-plugin:assemble' command

[spring-projects-issues]

Juergen Hoeller commented

Spring's Portlet support doesn't do anything about such PortletSession attributes. So whatever you stick into the session (or application) scope should still be there on later lookup. If it isn't, debug whether you're actually running within the same session... And what the current set of application-scoped objects looks like.

I suspect this is a problem with the Portlet container itself, not a Spring-specific problem.

(John, I'm assigning this to you since you might know typical pitfalls here...)

[spring-projects-issues]

Michal Capo commented

Reported to https://issues.apache.org/jira/browse/PLUTO-435

[spring-projects-issues]

John Lewis commented

Yeah, this is most likely a container problem. I downloaded the example application and I will attempt to reproduce the problem later today. I see an awful lot of Jetty/Pluto configuration in the example -- I will likely strip it down to a pure portlet webapp and deploy it into the standard Pluto/Tomcat container for testing.

[spring-projects-issues]

John Lewis commented

I slimmed down the project into a pure portlet webapp and deployed it into the Pluto 1.1.4 Tomcat bundle and I am not able to reproduce your problem. Can you try the same on your end and verify? The revised source code is attached as test1a.zip. Just run a 'mvn package' and then use the war file from the target directory. If you can then try deploying this webapp into your Jetty/Pluto environment to see what behavior you get.

[spring-projects-issues]

Elliot Metsger commented

This may be similar to another issue I saw in uPortal - UP-1816 http://www.ja-sig.org/issues/browse/UP-1816

In UP-1816 the Portal was rendering multiple portlets on a page, and each portlet was being rendered in its own thread. The request object was shared amongst each rendering thread, and that (along with some Tomcat-specific behavior regarding request wrapping) was seemingly causing session objects to disappear. In reality the thread rendering the portlet was getting back the incorrect session object on subsequent requests, making it appear to the portlet developer that session objects were disappearing. These problems didn't show up in the Pluto 1.1.4/Tomcat bundle because the Pluto portal renders portlets serially using a single thread. The portlets in the Pluto portal are JSP pages that use a Pluto tag library to call the render method on the portlet.

Did John's stripped-down webapp exhibit the bad behavior in the Jetty/Pluto environment? I can take a look too when I get a chance. I'm curious to see if this is a similar problem.

[spring-projects-issues]

Elliot Metsger commented

Perhaps Jetty renders JSP's simultaneously using multiple threads, instead of rendering them simultaneously using a single thread.

What happens if this test app is the only portlet on the portal page being rendered? Does the problem occur when there are multiple portlets in a layout?

I guess I should try it myself :-)

[spring-projects-issues]

Michal Capo commented

Actually no. With one portlet on the portal page it ends with the same exception.

[spring-projects-issues]

John Lewis commented

Michal, have you tried deploying the webapp from the version of your code that I uploaded? It would be interesting to have you deploy that Webapp into both Jetty and Tomcat (using the same version of Pluto) and see if that gives different results.

[spring-projects-issues]

Michal Capo commented

I found the problem. The session invalidate method was called on each request. And that happens because getLastUse (or something in that way) alway returned 0. So the difference between 'now' and 0 was greater than allowed inactive time. I fix it by setting max inactive time to Long.MAX_VALUE. But this is only half sollution.

[spring-projects-issues]

Juergen Hoeller commented

So is there anything we can do about this from Spring's side? Wondering about the status of this as a Spring issue...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I'll close this issue on Spring's side, since there doesn't seem to be anything we can do about it.

Juergen

[spring-projects-issues]

John Lewis commented

I agree -- this really isn't a Spring issue.