Problem with application context and session invalidation

[uze]

Hi,

I need to detect when a session expires to perform a cleanup in a database. I configured a HttpSessionListener class and registered it in web.xml. So far that works, however I'm quite puzzled on how to actually get the spring application context so I can call a bean defined in it!

Perhaps there's a listener for that in Spring? Any ideas?

Uze

[irbouho]

try the following inside your HttpSessionListener

import org.springframework.web.context.support.WebApplicationContextUtils;
import org.springframework.context.ApplicationContext;
...
public void sessionDestroyed(HttpSessionEvent event) {
  ServletContext servletContext = event.getSession().getServletContext();
  ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);
  ...
}

HTH

[uze]

Omar, thanks for the reply. However that does not seem to work, the line

ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext);

returns null.

However the servletContext is not, and debugging a bit, I found one of its attibute is of type XmlWebApplicationContext and
has its key= org.springframework.web.servlet.FrameworkServlet.C ONTEXT.reodatabase

Any hints?

[irbouho]

Uze,

I tried this code before posting it on the forum and It worked just fine
In my case, I registered the WebApplicationContext using org.springframework.web.context.ContextLoaderListe ner and did not change the default WebApplicationRoot.
How do you load your ApplicationContext ?

[uze]

Well, I'm no expert in those context things. My app server is websphere, and i registered a "org.springframework.web.servlet.DispatcherServlet " as the main servlet in my web.xml. I guess from there spring load the app-servlet.xml, which is, if I understand, the applicationContext? Should i set thing differently? Do you have any code/xml examples?

[irbouho]

uze,
the sample I posted shows how to access the global WebApplicationContext. Since your servlet is reodatabase, you can access the Servlet ApplicationContext using:

ServletContext servletContext = event.getSession().getServletContext(); 
  ApplicationContext context = (ApplicationContext) servletContext.getAttribute("org.springframework.web.servlet.FrameworkServlet.CONTEXT.reodatabase");

HTH

[uze]

Thanks Omar, but it seemed too much like a hack to me. So after quite a bit of reading, you were right, it was an issue with how the applicationContext is initialized.

In web.xml I've added a ref to ContextLoaderServlet and set the following:

<listener>
   <listener-class>com.ba.reo.mvc.SessionManager</listener-class>
</listener>  

<servlet>
   <servlet-name>context</servlet-name> 
	<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
   <load-on-startup>1</load-on-startup>
</servlet>

<servlet>
	<servlet-name>reodatabase</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<load-on-startup>2</load-on-startup>
</servlet>

...and I moved the needed beans in the applicationContext.xml file...works perfectly now! Thanks again for the help!

Uze

[irbouho]

welcome
Hope to see you in CRIM december 8.

[pjydc]

I use a HttpSessionListener to track users. This object depends on
other objects (beans). However, this listener stays in web.xml, not a Spring
app context, I also used the following to get context

ApplicationContext context = WebApplicationContextUtils.getWebApplicationContex t(servletContext);

and from the context to get beans.

However, I think this approach is not elegant except
reusing beans defined in a Spring app context. I hope to see
that Spring could has a class that always works as a http session listener,
and then a user-defined session listener in app context defines an association
with this spring session listener. In this way, the user listener
is completely defined and behaves like a normal bean.

Regards,
Pete

[chunhui]

Its gonna be ready probably in 2.0 M2. Alef Arendsen is working on it.

Its in JIRA:
http://opensource2.atlassian.com/pro...browse/SPR-437

finally....not a big prob, but taken awefully long