You can use RWT.getSessionStore().getHttpSession() to obtain a reference
to the HttpSession. But you need to make this call from the UI thread to
get the connection to the user session. Does that help?
Sure, there are as many UI threads as there are active user sessions.
But you don't have to pass any information as long as the call is made
in a UI thread, e.g. from a listener or in a display.asyncExec() and the
services in this call chain call each other methods directly
Your statements contractdict each other! Your UserAdminService is
*stateful* because it accesses a static variable, so all and everyone
depending on it is getting stateful as well.
Am 22.11.12 13:17, schrieb Wim Jongman:
> We have a large number of layered osgi components (stateless "singleton"
> services) that do not have the notion of sessions.
> From the RAP ui there is a call to say "ItemService", ItemService is
> dynamically bound with a UserAdmin service.
> When ItemService is called to receive items, it calls a method in
> UserAdminService to see if the user is authorized.
> In the RCP environment UserAdminService uses a static
> UserProfile.getLoggedinUser() method but this approach will obviously
> not work in RAP.
> Is there a way to get to the RAP session information from
> UserAdminService without changing the method signatures?
> so in short
> RAP UI (1..*) --> ItemService (1) --> UserAdmin (1) --> ?session?
> Thanks for helping,
That's exactly the big drawback. You need to call the service on the
UI-Thread so stuff you pushed into a background-thread can't access the
Am 23.11.12 15:01, schrieb Ralf Sternberg:
> Sure, there are as many UI threads as there are active user sessions.
> But you don't have to pass any information as long as the call is made
> in a UI thread, e.g. from a listener or in a display.asyncExec() and the
> services in this call chain call each other methods directly
> Rest regards, Ralf
This is a problem with any multi-user system. If you need to access a 'singleton' scoped to a specific user have a look at org.eclipse.rap.rwt.SingletonUtil to provide your scoped singletons and org.eclipse.rap.rwt.lifecycle.UICallBack.runNonUIThreadWithFakeContext(Display, Runnable) This will allow you to access the singletons on a background thread. You'll still need to save a reference to the Display instance for the particular user though.
In my single-sourced project I used fragments to provide my own "singleton service". The RAP version used org.eclipse.rap.rwt.SingletonUtil and the RCP version used a HashMap.
Right, you *can* access session-scoped data from a background thread if
you have a reference to the user's display. I was hesitating to make
this statement in the first place because this API is under revision for