Question

I have a Web Application that I’m trying to move from Sun Application Server V9 to Glassfish V2.1.1

I’m using Netbeans 6.0.1 to develop the App, and it’s using JSP, SessionBeans and JDBC to connect to MySQL.

I’ve made good progress and can compile and deploy the App. to Glassfish OK.
The App starts and I takes me to my login page, where I can login OK.

However, I can see that all of my SessionBeans repeatedly call init() and destroy() methods as each JSP page is rendered.

My Session Bean extends AbstractSessionBean


public class SessionBean1 extends AbstractSessionBean {


Using Netbeans Debug tool I have tracked down the LifecycleListener.attributeReplaced(HttpSessionBindingEvent event) method that calls the destroy() and init() methods on my AbstractSessionBeans


public void attributeReplaced(HttpSessionBindingEvent event) {

    // If the old value is an AbstractSessionBean, notify it
    Object value = event.getValue();
    if ((value != null) && (value instanceof AbstractSessionBean)) {
        ((AbstractSessionBean) value).destroy();
    }

    // If the new value is an AbstractSessionBean, notify it
    value = event.getSession().getAttribute(event.getName());
    if ((value != null) && (value instanceof AbstractSessionBean)) {
        ((AbstractSessionBean) value).init();
    }

}

In Netbeans 5.5 and Sun Application Server V9 the AbstractSessionBean Session Beans work fine and don’t have their init() and destroy() methods() called all the time.

I’ve checked that my Session Beans are in the faces-config.xml.

So, my feeling is that it’s my configuration of Glassfish 2.1.1…

Please can you help?

Thanks

P.S.

Just to add to this….

I can deploy exactly the same app from Netbeans 6.0.1 to:

• Sun App Server V9 and it works fine
  with the session beans init() method
  only being called once when the
  session is created

• Glassfish V2.1.1 and the Session Bean
  init() and destroy() method get
  called repeatedly.

Answer 1

So, a new session is started on each request. This can mean that the client or server doesn’t support cookies, or the webapplication didn’t have URL rewriting properly implemented for the case that the client has cookies disabled.

Tracking the HTTP request/response headers using a tool like Firebug must give new insights. On the very first request on a new client-server session, the server should have set the Set-Cookie header in the response with the session ID:

---

In all subsequent requests during the same client-server session, the client should have set the Cookie header in the request with the same session ID:

---

If either of those is missing or different, then you should know the root cause of the problem.