Session creation in AbstractSessionBeanStore (Weld 1.1.4)

[s.moschel]

We are running some web applications on Glassfish 3.1.2 Application Server. Our security framework is Apache Shiro. Shiro runs in native mode. That means that shiro creates its own session cookie and has its own session handling. Our problem is that Weld creates an session before Shiro can create it.

Session creation happens in:

• org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore (Line 58).

The result is that we have two sessions. One session created by Weld(JSESSIONID), another session created by Shiro. Is there any way to avoid multiple sessions? I mean a switch that weld uses an existing session instead of creating its own. This behaviour causes many problemns in our applications.

[alesj]

Weld uses plain Servlet API to create a session.

Dunno how Shiro does it, but it looks like it avoids Servlet API?

Or I would need more details or even better, an example / test.

[eurokey]

We use the native Sessions from Shiro. According to their documentary Shiro is wrapping all Request that create Sessions. However we still have the problem, that we have 2 Sessions for each User, one from Glassfish and one from Shiro.

Native Sessions

If you want your session configuration settings and clustering to be portable across servlet containers (e.g. Jetty in testing, but Tomcat or JBoss in production), or you want to control specific session/clustering features, you can enable Shiro's native session management. 

The word 'Native' here means that Shiro's own enterprise session management implementation will be used to support all Subject and HttpServletRequest sessions and bypass the servlet container completely.  But rest assured - Shiro implements the relevant parts of the Servlet specification directly so any existing web/http related code works as expected and never needs to 'know' that Shiro is transparently managing sessions.

http://shiro.apache.org/web.html#Web-sessionManagement

[alesj]

But rest assured - Shiro implements the relevant parts of the Servlet specification directly so any existing web/http related code works as expected and never needs to 'know' that Shiro is transparently managing sessions.

Hmmm, looks like this is not exactly true ...

and bypass the servlet container completely

This is probably the problem.

You're on your own here, as this is too custom to be generically handled by Weld.

But I'll definitely try to help you with any questions you might have.

[zoladkow]

I'm terribly sorry to dig up such an old thread, but I am currently facing the same problem.

Weld 2.2.2 Final on Glassfish 4.1 b13. The project is using Shiro 1.2.3

I need Shiro's "native" session management because of greater configurability than container can offer. At first I noticed that JSESSIONID is created sometimes as 0c1affa8-9d4e-498f-a65e-b95c46cabeae and then as ef85f6e58b80ab978ee9ea23501c. Which did not make any sense. The workaround was to set a different session cookie name. But then, I noticed that some session bean does not get recreated after user re-logs into the application.

Debugging showed that event though Shiro is on top of filter chain and properly wraps the request (in this case org.apache.catalina.connector.RequestFacade which in trun wraps com.sun.enterprise.web.pwc.connector.coyote.PwcCoyoteRequest), Weld, which is deeper in the chain, goes straight to obtain the session from RequestFacade instead.

This behavior seems to be the root of problem.

It is not Weld that should be generic in this case - I believe it should only respect and make use of the request wrapper that was passed through the filter chain.

[zoladkow]

Problem went away when I replaced weld-osgi-bundle from Glassfish modules with latest weld-osgi-bundle-2.2.11.Final-glassfish4.jar - now SessionBeans get destroyed with Shiro-managed session, which is good. And also regular SessionListeners are not working anymore (which is expected as Shiro has his own listener mechanism).

Before I went for upgrading the bundle I noticed how Weld was initializing it's session store (or session holder) - it was doing it even before the filter chain started, using non-standard server valves specific to Glassfish (or rather Catalina). So this was true for 2.2.2,  don't know how it happens now in 2.2.11 but at least works as I would expect.

All in all I am happy with Weld, good stuff, now even better