HttpSessionListener
Hello I'm trying to write a bean so when sessions are closed, database connections and other resources are released. I realise when the sessionDestroyed method is called on HttpSessionListener the session is already invalidated (I would like to know why such a design decision was made there, it seems wrong). Anyway, as I need to be able to map stuff to a session I'm trying to write a listener where I can say For this newly created session, hold on to this object. So when the session is destroyed, the object can be retrieved and methods called upon it (such as close db connections). My question. How do I get to the HttpSessionListener from the application itself? I realise I have to define the listener in the web.xml, but I'd be quite shocked if this could not be done another way. Thanks John Baker -- John Baker, BSc CS. Java Developer, TEAM EAA.. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
Mmm. It would appear I can only get the session if the value is defined in the Context in server.xml. Ie I cannot define it in the default location in server.xml (where the catalina SingleSIgnOn is commented) and expect it to work. Is this correct? And if so, can I achieve what I want to, ie a valve for all contexts? John On Sunday 30 June 2002 21:38, John Baker wrote: On Sunday 30 June 2002 9:35 pm, Craig R. McClanahan wrote: Hmm ... this is baslically how the standard form-based login implementation creates a session, except that it goes on and gets the internal Session object ... That's what I thought. I presume you're trying to create the session *before* calling context.invokeNext(), right? If you don't the response will have already been committed so creating a new session would be ineffective. Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Monday 01 July 2002 10:43, Henner Zeller wrote: Hi, Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! Maybe this is a similar problem I had when trying to fix the bug described in my previous posting: the Context is not yet set (HttpRequestBase.setContext()) at that stage - thus HttpServletRequest.isRequestSessionIdValid() will return false (see implementation of isRequestSessionIdValid()). Yes, I was thinking this when I read your mail. I'm now putting a valve in each relevant Context and using a static Hashtable. Sick, I know, but it seems I have no other choice for now. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cookies
Hi, Has anyone found that browsers refuse to delete cookies when you do Cookie.setMaxAge(0); ? I can not get any browser to delete a cookie! Having looked at the response the Set-Cookie: header appears correctly formed. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
That Cookie thing
It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 12:59, peter lin wrote: if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. I know this ;-) But I'd forgotten to put the / there, and assumed the browser would assume this if no / was passed to it. However they don't, so I was suggesting that if a Cookie has no path set then one should be written by default as a totally useless header is currently written in the form: Set-Cookie: someName=someValue; expires and due to the lack of a path, every browser ignores it. peter John Baker wrote: It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore this,
would it be more useful to provide a default in some way so it isn't ignored?
The chances of getting all those three to stick to the spec are low ;-) Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies,
and infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:38, peter lin wrote: John Baker wrote: Well a reliable source tells me that there is no w3c spec for Cookies, and infact the concept was conjured by Netscape. There is an RFC spec for Cookies, but it's largely ignored. So as the useful browsers out there ignore Cookie requests without a path, it might be handy to add it by default so other people don't spend an hour or two sitting there thinking Why doesn't this work?. The current context path would be handy, so the response code could look like this: http://wp.netscape.com/newsref/std/cookie_spec.html http://www.ietf.org/rfc/rfc2109.txt Too many specs to keep track of. I disagree the default should be set to /, since that isn't how other web/app servers handle it. I know both websphere and weblogic follow netscapes suggestion. The spec might be bad and probably is, but since that's how most browsers handle it, changing might cause more problems than it solves. just my .2 Yes, / is bad, I think I'll forget that. The default context would be more handy, and a warning would be very handy. But most browsers don't handle it, infact, I can't find one that does (although I've only tried IE/Moz1.0/Konq). But if that collection don't handle it, any cookie sent without a path is almost totally useless. I vote a warning. Warnings are great, they save wasting time. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
No, you don't find out quickly if you don't know what you're doing and you're
newish to web programming. You only find out if you've got a good knowledge
of web browsers and you realise that although path is optional, the majority
of browsers ignore it in some cases. For example, this problem only occurs if
a Cookie will be deleted (setting maxAge to 0) and it has no path. Even the
best web programmers will take some time to figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most browsers
will totally ignore it.
Therefore you've just made many developers very happy with you for providing
such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 14:03, Martin van den Bemt wrote:
Just add something to the docs.. At least we can see rtfm ;) (with
some nice pointers to the specs)
Quite. Documentation is everything.
But the more I think about it, a newbie logger of some kind could be a great
sell point in terms of making people trust and use Tomcat over other products
(believe it or not, people like http://www.barclays.co.uk and
http://www.elephant.co.uk have picked silly Java servers over Tomcat).
Getting more business using Tomcat would be ace, and stuff like
localhost_moron_log.txt would be a great way to make development even
quicker and businesses happier (ie lower costs).
I'll do some work now ;-)
John
Mvgr,
Martin
On Mon, 2002-07-01 at 14:55, John Baker wrote:
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did
and can fix it.
No, you don't find out quickly if you don't know what you're doing and
you're newish to web programming. You only find out if you've got a good
knowledge of web browsers and you realise that although path is optional,
the majority of browsers ignore it in some cases. For example, this
problem only occurs if a Cookie will be deleted (setting maxAge to 0) and
it has no path. Even the best web programmers will take some time to
figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most
browsers will totally ignore it.
Therefore you've just made many developers very happy with you for
providing such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to
be set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without
a path, it might be handy to add it by default so other people
don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could
look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently
written
in
the form
Re: Valves, requests and getting the session
On Monday 01 July 2002 6:49 pm, Craig R. McClanahan wrote: One workaround is to put your valve inside each Context element (either directly or -- I think this works, but have never tried it -- by embedding them in a DefaultContext that sets the properties for all contexts in that host. That's what I did, with a static Hashtable to bridge the different instances. Not perfect, but it works very nicely now! John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Valves, requests and getting the session
Hello.
I'm am trying to write a Valve, very much like SingleSignOn but for our
authetnication system that uses more than just a username and password. I
want my Valve to pass login information from one Session to another when a
user uses different webapps (Contexts).
I am nearly there codewise, but have a small problem. I do not seem to be able
to get the session from the request! I've tried calling request.getSession()
and request.getSession(true) yet both return null. It's hardly worth pasting,
but:
public void invoke(Request request, Response response, ValveContext context)
throws IOException, ServletException
{
System.out.println( ((HttpRequest)request).getSession(true) );
Will always print null.
I assume I can get at the session from this level and I'm obviously doing
something dumb. Are there any obvious things I should check?
Thanks
John Baker
--
John Baker, BSc CS.
Java Developer, TEAM Slb. (http://www.teamenergy.com/)
The views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: configure tomcat (web-inf)
On Sunday 30 June 2002 7:09 pm, Juan Antonio Herraiz wrote: I want to know how I have to configure tomcat to run a jsp file with imports jar files, by example, xalan, jdom, xindice,... I don't know if I have to put this jar files in the CLASSPATH, copy them into the web-inf/lib... etc Sounds like you want to read up on the structure of webapps. webapps/myapp/someJspPage.jsp webapps/myapp/WEB-INF/classes classes go here webapps/myapp/WEB-INF/lib jars go here John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sunday 30 June 2002 7:32 pm, Peter Lin wrote:
--- John Baker [EMAIL PROTECTED] wrote:
Hello.
I'm am trying to write a Valve, very much like
SingleSignOn but for our
authetnication system that uses more than just a
username and password. I
want my Valve to pass login information from one
Session to another when a
user uses different webapps (Contexts).
I am nearly there codewise, but have a small
problem. I do not seem to be able
to get the session from the request! I've tried
calling request.getSession()
and request.getSession(true) yet both return null.
It's hardly worth pasting,
but:
public void invoke(Request request, Response
response, ValveContext context)
throws IOException, ServletException
{
System.out.println(
((HttpRequest)request).getSession(true) );
Will always print null.
Shouldn't you be using this instead?
(HttpServletRequest request, HttpServletResponse
response, ValveContext context)
Err, the inteface Valve clearly defines:
public void invoke(Request request, Response response, ValveContext context)
throws IOException, ServletException;
Also, why are you casting HttpSession to HttpRequest?
I'm not, I'm casting request to HttpRequest so I can call getSession. I did
cut some of my code but I do check to make sure request can be casted.
See org.apache.catalina.authenticator.AuthenticationBase and the method
getSession(HttpRequest request, boolean create);
as this gives a clear example of what I'm trying to do. yet it doesnt work for
me!
John
--
John Baker, BSc CS.
Java Developer, TEAM Slb. (http://www.teamenergy.com/)
The views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sunday 30 June 2002 9:25 pm, Craig R. McClanahan wrote: Will always print null. I assume I can get at the session from this level and I'm obviously doing something dumb. Are there any obvious things I should check? Try this slight variation (based on what Catalina does in the getSession() method of AuthenticatorBase): HttpServletRequest hrequest = (HttpServletRequest) request.getRequest(); HttpSession session = hrequest.getSession(true); Already tried that, and sadly it didnt work :( The code you quoted above shouldn't actually compile, because you're calling getSession() on the internal HttpRequest interface, but there is no getSession() method on that interface. You need the extra getRequest() call to get to the HttpServletRequest object that would be handed to a servlet -- that's the one with the getSession() method that operates as you need it to. Yea I know, I copied rather than pasting and mistyped the casting. The mystery goes on. John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Valves, requests and getting the session
On Sunday 30 June 2002 9:35 pm, Craig R. McClanahan wrote: Hmm ... this is baslically how the standard form-based login implementation creates a session, except that it goes on and gets the internal Session object ... That's what I thought. I presume you're trying to create the session *before* calling context.invokeNext(), right? If you don't the response will have already been committed so creating a new session would be ineffective. Yes, I am. I need to check to see if certain objects are in the session and if not, see if they are in another session that is pointed to by the Cookie id. It's like SingleSignOn, but slightly different. However I'm a bit confused to why I can't get a session, even when the rest of the app (the jsp pages etc) are making good use of it., The headers also show the session id, but oddly enough calling HttpServletRequest.SessionIdFromCookie() returns true, but HttpServletRequest.isRequestSessionIdvalid() returns false! John -- John Baker, BSc CS. Java Developer, TEAM Slb. (http://www.teamenergy.com/) The views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
