Keep it simple. Try this first, if your problem is the "missing"
attribute from http session. At least this what i would do in your
place:

>       Maybe, you're getting a new session every time you're calling 
> this page
> and "settings" reference is getting null. I *think* this can happen if:
> 
>       - Something is invalidating the session before request.getSession get
> called;
>       - Your http client don't support cookies or is not sending the same
> cookie every time;
>       - URL rewriting is disabled.
> 
> 
>       Look the value returned by request.getRequestedSessionId() or
> session.getId(). If the same user call this page a lot of times, the
> same id should be returned. 
>       The best approach is look this value (session id) right before
> session.setAttribute(ATTR_NAME, settings) and
> session.getAttribute(ATTR_NAME) have been called.
> 

        What is happening between set and getAttribute ? Do you have the same
session id before calling each one ?


        After that you could try to imagine more complex scenarios (more
unlikely to happen) like: Are you Tomcat running behind a web server
with load balance ? Is the web server proxying http requests correctly
or it is sending each request to a different Tomcat instance/pair ? Are
you accessing Tomcat hostname directly or throw a "logical"/mapped
hostname resolved to distinct places/IPs ?
        




On Fri, 2009-07-03 at 16:41 -0300, Daniel Henrique Alves Lima wrote:
> Hi, Achal.
> 
> On Sat, 2009-07-04 at 00:47 +0530, Achal Patel wrote:
> > Hi Daniel,
> > 
> > Yes, at Weblogic, request.getSession() is returning a non-null value AND
> > "(Settings) session.getAttribute(ATTR_NAME)" is
> > 
> > > working.
> 
> Ok.
> 
> > 
> > On Tomcat out of 5 requests this is happening for 2 times.
> > 
> > Let me explain the deployment architecture:
> > 1. User invokes JSP page
> > 2. JSP calls homegrown framework which performs operation and generates XML
> > response
> >       2.1 This XML framework also works on sessions and request objects.
> > 3. XSLT transforms XML into HTML and displays on UI
> 
> In this framework is there any kind of distributed engine or
> configuration that can be wrong ? Is it possible that some is running
> over Tomcat and some over Weblogic (like jsp in Tomcat are doing
> redirects to a servlet in Weblogic) ? 
> 
> 
> > 
> > It looks like JSP and Servlets are using different sessions ???
> 
> I don't think so. Try to print/debug session id and you will find out.
> 
> 
> 
> > 
> > 
> > On Fri, Jul 3, 2009 at 9:05 PM, Daniel Henrique Alves Lima <
> > email_danie...@yahoo.com.br> wrote:
> > 
> > > Hi, Achal.
> > >
> > >
> > > On Fri, 2009-07-03 at 19:48 +0530, Achal Patel wrote:
> > > > Its basically below:
> > > >
> > > > HttpSession session = request.getSession();
> > > > Settings settings = (Settings) session.getAttribute(ATTR_NAME);
> > > >
> > > > I debugged it and got to know that session is getting null and
> > again
> > > > invoking the same resource from UI serves fine.
> > > > The same is working fine on Weblogic.
> > >
> > > Am i missing something or you're saying that when session is null
> > > "(Settings) session.getAttribute(ATTR_NAME)" works ?
> > > Are you sure ?
> > >
> > > Or you're saying that, at Weblogic, request.getSession() is
> > returning a
> > > non-null value AND "(Settings) session.getAttribute(ATTR_NAME)" is
> > > working ?
> > >
> > > >
> > >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-- 
"If there must be trouble, let it be in my day, 
 that my child may have peace."

Thomas Paine


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to