Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Emulating JSP 'usebean' command in a Servlet

 
Harry Wood
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Weird problem, and difficult to describe.

I'm trying to create a servlet which behaves in exactly the same way as an existing JSP. The JSP uses the special (JSP only) 'usebean' command.

I will have to explain what the bean is.
I have a web-app containing JSPs and a bean class, supplied as a vendor product (TIBCO InConcert ICWeb) which I am customising. The IcClient bean maintains a connection to an external system (InConcert). Calling the method 'isConnected' on this bean, tells us if the user is logged on.

The 'login.jsp' supplied in the web-app is working fine. It contains a 'usebean' command, and calls an initialisation method on the bean to set it up. All subsequent JSPs will find that the bean's 'isConnected' method returns true. The connection inside the bean is persisting between requests.

Now I need a servlet which does exactly the same thing. I tried writing this myself, so that it does the following:
  • checks if the bean object is allready in the session.
  • ...if not it creates a new instance.
  • Calls the bean's initialisation method to make a connection.
  • Writes the bean object back to the session.


  • This is not working. All the above steps execute fine, but when I navigate to another page, the bean's 'isConnected' method returns false.

    For weeks I have been scratching my head, trying to figure out why this is not doing exactly the same thing as the JSP.

    Today, out of desperation, I abandoned my own servlet code, and took the servlet class which my webserver generated from 'login.jsp'. I renamed this and put it in with my servlet package, but still the servlet is behaving differently to the JSP, and 'isConnected' winds up as false.

     
    Bear Bibeault
    Author and ninkuma
    Marshal
    Posts: 65537
    108
    IntelliJ IDE Java jQuery Mac Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Things to check:

    1) Are your servlet and subsequent JSP 'talking' to the same session?
    2) Did you name the session attribute the exact same name (case and all) as the useBean id?
    3) Are you getting a new instance of the bean in the JSP?

    How about posting your servlet code (use UBB code tags) that performs the faux useBean steps?
     
    Harry Wood
    Greenhorn
    Posts: 16
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    When writing the servlet myself I looked at the servlet code generated from the login.jsp, and decided these are the bits I need for getting the bean from the session. (Note the logic to create a bean instance if it is not already present in the session)



    Lower down I just do this to set the object back to the session if I've managed to make a connection.



    After that I tried adding a test which pulls the bean out into a different variable, and check if it it's still connected. It is.

    But if I open the next JSP in the same browser, the bean object is retreived, but is no longer connected.

    So I was thinking maybe there's something I'm not understanding about 'session.setAttribute'. The generated servlet does not do this in fact. At least not directly. It winds up its operations with a '_jspxFactory.releasePageContext' (internal JSP engine tricks which presumably includes setting the bean back to the session)

    but even if 'session.setAttribute' is not behaving as expected, how is it possible that running the generated servlet code (complete with _jspxFactory.releasePageContext) as a servlet, does not have the same effect as running the JSP?
     
    Bear Bibeault
    Author and ninkuma
    Marshal
    Posts: 65537
    108
    IntelliJ IDE Java jQuery Mac Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Lower down I just do this to set the object back to the session


    This is a harmless but unecessary step. The bean is already set into the session.

    Did you verify the other things I asked about? Are the servlet and the JSP referenceing the same session? If so, is the bean instance referenced in the JSP page the same instance as the bean referenced in the servlet?

    If you do not know how to check the above, those are debugging techniques you need to learn to perform.
     
    Harry Wood
    Greenhorn
    Posts: 16
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thankyou bear. You nudged me in the right direction, and now my login servlet is working like a dream.

    I will describe how what I did, for the benefit of others.

    It turns out that the servlet generated from the JSP does work correctly, in exactly the same way as the JSP. I was being stupid and looking at the wrong URL while testing it.

    I only noticed this while doing as you suggested and checking if I was dealing with the same session object. I did this by doing a toString on both the session object and the bean object, to compare the object IDs. (Is that what you meant? Probably there is some better way to test this)

    You said it was harmless but unnecessary to set the bean back to the session with the session.setAttribute("icClient", icClientBean); line. So I tried taking this out. In fact I had suspected this already, and had tried it before.

    The resulting effect is that the login servlet works, and re-logs-in sucessfully after going to a 'logout.jsp' (which does session.invalidate). But then it breaks in the other two cases: if the session is destroyed because the server is re-booted, or if the session times out.

    Then it ocurred to me that these two cases are where the bean is null and therefore must be re-created. So the fix which nailed this problem was to set the bean back to the session, only at the top in position shown here:



    So it seems 'harmless but unnecessary' was not entirely correct. Calling session.setAttribute("icClient", icClientBean) was actually breaking the connection. In the absence of this call at the bottom, the connection persisted correctly. (something to do with serialisation?)

    However it is necessary to make this call at the top, if the bean was found to be null in the session. Which seems obvious now that I look at it

    I can't believe it finally works just by moving that line. Thanks for your help with getting to the bottom of this!
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!