Losing portelt session after every request

Question

Using bwa wl portal server 8.1 on wxp sp2
Hello all
We wrote some JSR 168 compliant portlets and deployed them accoring to the bea doc. Basically our portlets seem to work. However, there are some issues that could be tracked down to one problem:
Somehow the session gets lost on every request! One action request uses the same portlet session during action/render cycle, but two consecutive calls to the same portal page yield different sessions, so holding any session variables is next to useless.
The deployment szenario is this:
Using bea workshop i created an application and deployed our complete jsr168 portal application. Since bea does not enforce a login/does not impose any login restrictions, i created another application which imported a second portal project, which used the first application as a wsrp portlet provider.
The second application merily consists of a web.xml containing only security restrictions:
<web-app id="WebApp">
<display-name>Livelink Portal Integration Kit</display-name>
<security-constraint>
<web-resource-collection>
<web-resource-name>Portal</web-resource-name>
<description>Security constraint for the whole portal</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>all users</description>
<role-name>Users</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>Users</role-name>
</security-role>
</web-app>
At first i tried to add these security restrictions to the wsrp application but then the wsrp provider could not be reached so i split the applications.
So - how do i prevent bea from created a bunch of sessions? What am i doing wrong?

Answer 1

Hi
In server.xml, do you have cookies=true for both contexts (and the defaultContext)? I'm not sure how it would behave if one context was true and the other false.
Alternatively, could it have something to do with the crossContext attribute?
--Jon