• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Emulating JSP 'usebean' command in a Servlet

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

     
    Sheriff
    Posts: 67645
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
    Sheriff
    Posts: 67645
    173
    Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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!
     
    What do you have to say for yourself? Hmmm? Anything? And you call yourself a tiny ad.
    Free, earth friendly heat - from the CodeRanch trailboss
    https://www.kickstarter.com/projects/paulwheaton/free-heat
    reply
      Bookmark Topic Watch Topic
    • New Topic