Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 364310

Summary: [WebClientState] ThreadLocal not persistent over async ServerSessions
Product: z_Archived Reporter: Beat Schwarzentrub <bsh>
Component: ScoutAssignee: Project Inbox <scout.core-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 350268    
Bug Blocks:    
Attachments:
Description Flags
Proposed change
none
mylyn/context/zip none

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)