Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 364310 - [WebClientState] ThreadLocal not persistent over async ServerSessions
Summary: [WebClientState] ThreadLocal not persistent over async ServerSessions
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Scout (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 350268
Blocks:
  Show dependency tree
 
Reported: 2011-11-21 07:15 EST by Beat Schwarzentrub CLA
Modified: 2021-08-19 11:05 EDT (History)
0 users

See Also:


Attachments
Proposed change (3.26 KB, patch)
2011-11-21 08:46 EST, Stephan Leicht Vogt CLA
no flags Details | Diff
mylyn/context/zip (32.53 KB, application/octet-stream)
2011-11-21 08:46 EST, Stephan Leicht Vogt CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Beat Schwarzentrub CLA 2011-11-21 07:15:57 EST
Build Identifier: 

Currently, the Scout rt-server is using the class WebClientState to determine whether the current request's origin is a rich client (Swing, SWT) or a web client (RAP). The corresponding flag is set when the Scout session is extracted from the HTTP session (ServiceTunnelServlet).

However, the static methods of WebClientState might return a wrong result when called in an other ServerJob (i.e. Thread) that is spawned from the original ServerJob. The WebClientState information is bound to the current thread and is _not_ correctly transferred when changing threads.

PROPOSED SOLUTION:
Move WebClientState to the rt-client plugin, such that only the client can access the information anymore. For the server side, a new attribute should be added to the ServerSession (as the ServerSession is already correctly transferred to all subsequent ServerJobs).

See also bug 350268.

Reproducible: Always
Comment 1 Stephan Leicht Vogt CLA 2011-11-21 08:07:17 EST
I do not have the same opinion. The server has to know, what the capabilities has the current client (richclient/webclient/tablet(future)/phone(future)). For example the method getFontSizeUnit is necessary when HTML is generated on the server the correct unit (px, pt) has to be written.

I think we must be sure to write the webClientState information correct also to asynchronous server jobs. Would that be possible?
Comment 2 Stephan Leicht Vogt CLA 2011-11-21 08:46:03 EST
Created attachment 207302 [details]
Proposed change

I discussed this with my colleague and came with the proposed change. The webclient state would be written to the ThreadLocal in the DefaultTransactionDelegate inside a try-finally. If someone would start a asynchronous call inside a transaction it would be necessary to give the webclientstate information to the new job. Because a new job could also be a scheduler-job without a frontend only the developer is able to determine what information he needs in a new async job.
Comment 3 Stephan Leicht Vogt CLA 2011-11-21 08:46:05 EST
Created attachment 207303 [details]
mylyn/context/zip
Comment 4 Stephan Leicht Vogt CLA 2011-11-25 05:45:16 EST
Checked in as proposed to trunk for eclipse juno 3.8.0
Comment 5 Matthias Zimmermann CLA 2012-07-09 06:49:54 EDT
ticket closed.
deliverd as part of eclipse scout 3.8.0 (juno release train)