getThreadLocalRequest() returns null

1,420 views
Skip to first unread message

j.casey...@gmail.com

unread,
Oct 6, 2007, 10:18:39 PM10/6/07
to Google Web Toolkit
First, here is my setup: hibernate4gwt, gwt-sl 0.1.4, gwt 1.4.60, osx.

I am calling a remote service that extends HibernateRemoteService
which of course extends RemoteServiceServlet. When my service is
invoked and I try to get the current user session,
getThreadLocalResponse() always returns null. Has anyone else
experienced this issue? I found the following thread but it is from
last year and it no longer seems relevant since both Hibernate4GWT and
gwt-sl have evolved significantly since November.

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/26487843cdfd89df/866fe9cae9d2961f?lnk=gst&q=getThreadLocalRequest()+null&rnum=1#866fe9cae9d2961f

Thanks for any help.

Casey

j.casey...@gmail.com

unread,
Oct 6, 2007, 10:18:42 PM10/6/07
to Google Web Toolkit

noon

unread,
Oct 7, 2007, 4:03:29 AM10/7/07
to Google Web Toolkit
Hello Casey,

Can you send a snipset of code ?
I don't know if GWT-SL uses the current local thread, but
hibernate4gwt does (to store the HTTP session in the current local
thread).

Regards
Bruno

On 7 oct, 04:18, "j.casey.one...@gmail.com" <j.casey.one...@gmail.com>
wrote:


> First, here is my setup: hibernate4gwt, gwt-sl 0.1.4, gwt 1.4.60, osx.
>
> I am calling a remote service that extends HibernateRemoteService
> which of course extends RemoteServiceServlet. When my service is
> invoked and I try to get the current user session,
> getThreadLocalResponse() always returns null. Has anyone else
> experienced this issue? I found the following thread but it is from
> last year and it no longer seems relevant since both Hibernate4GWT and
> gwt-sl have evolved significantly since November.
>

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

j.casey...@gmail.com

unread,
Oct 7, 2007, 11:18:08 AM10/7/07
to Google Web Toolkit
Thanks for the response. Ok here is my code. It's pretty simple.

public class LoginServiceImpl extends HibernateRemoteService
implements LoginService

private static final long serialVersionUID = -6167290614292255786L;

private AuthenticationService authenticationService;

public LoginServiceImpl ()
{

}

public boolean login(String username, String password) {
if(StringUtils.isEmpty(username) || StringUtils.isEmpty(password))
return false;

//try to read the session ID. This fails.
Long sessionId = getThreadLocalRequest().getSession().getId();

return getAuthenticationService().loginUser(username, password);
}

/**
* Spring Bean
*/
public AuthenticationService getAuthenticationService() {
return authenticationService;
}

public void setAuthenticationService(
AuthenticationService authenticationService) {
this.authenticationService = authenticationService;

noon

unread,
Oct 8, 2007, 3:23:46 AM10/8/07
to Google Web Toolkit
OK, I think that I have an explanation.
I do not know much GWT-SL, but it seems to me that they are using a
front-end servlet to redirect input request to the right Spring bean.
So, that's this redirection instance that inherits from RemoteServlet
and is the active servlet where is stored the HTTP session.
Your Spring bean, even if it inherits from HibernateRemoteService, is
*not* the servlet used by GWT, so it has no session in current local
thread.

To check if I am right, you can try to bypass the GWT-SL redirection
servlet by calling directly your LoginService (in the gwt.xml file).

Regards
Bruno

On 7 oct, 17:18, "j.casey.one...@gmail.com" <j.casey.one...@gmail.com>
wrote:

George Georgovassilis

unread,
Oct 8, 2007, 3:49:28 AM10/8/07
to Google Web Toolkit
You can also use the SL's ServletUtils.getRequest() method which
retrieves the current session from a thread local instance setup by
the SL.

j.casey...@gmail.com

unread,
Oct 8, 2007, 9:12:27 AM10/8/07
to Google Web Toolkit
George and Noon, thank you for your responses. I will try out these
suggestions tonight.

On Oct 8, 3:49 am, George Georgovassilis <g.georgovassi...@gmail.com>
wrote:

AB

unread,
Nov 14, 2007, 3:37:09 PM11/14/07
to Google Web Toolkit
Any resolution on this. I suspect it is related to
http://groups.google.com/group/Google-Web-Toolkit/msg/d34fbd167b0fe024
There does appear to be a problem with getThreadLocalRequest() at
least in the sense in which one would expect it to work.
I am seeing a similar problem

George Georgovassilis

unread,
Nov 14, 2007, 5:44:52 PM11/14/07
to Google Web Toolkit
It probably is not related. What Klaus described in his post is that a
new session for every request is generated - which has to do with his
page not establishing an http session and returning that in the
jsessionid response header. If everything else works with SL and your
services are being invoked normally, ServletUtils.getRequest() will
do the job. Also check out the other static methods on that utility
class.

On Nov 14, 9:37 pm, AB <abere...@drillinginfo.com> wrote:
> Any resolution on this. I suspect it is related tohttp://groups.google.com/group/Google-Web-Toolkit/msg/d34fbd167b0fe024

AB

unread,
Nov 24, 2007, 2:51:18 PM11/24/07
to Google Web Toolkit
I just wanted to post a followup for whomever's benefit. Based on my
investigation, here is my problem and analysys

I have a simple app that makes synch callbacks every N seconds. I
noticed on firefox, but not on IE, that the servlet that handles the
callback gets a different session
when it calls getThreadLocalRequest() .getSession() than the session
that served the initial jsp page (the initial jsp page had the gwt js
link, etc).

It turns out in my case that the issue has nothing to do with
getThreadLocalRequest() or even gwt. The fundamental problem is that
when the first jsp page is served to the browser, the http header has
a set-cookie with a jsessionid=whatever as expected. However, when
the browser requests the .js file that "boots" the gwt app, the
response has another set-cookie with a different jsessionid. This is
a flaw in the appserver (in my case, resin-2.1.17) which I theorize is
related to thread handling (IE perhaps requests the .js page with
different timing). In any event, changing my app server to
resin-3.0.24 fixed the issue.

Reply all
Reply to author
Forward
0 new messages