CODEWITHSUNDEEP
javajspsessionglassfish
SteveGreenslade
SteveGreenslade

Reputation: 190

Glassfish 2.1.1 - Session Beans repeatedly call init() and destroy()

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:

Upvotes: 2

Views: 720

Answers (1)

BalusC
BalusC

Reputation: 1108712

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:

alt text

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:

alt text

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

Upvotes: 1

Related Questions