Eclipse Community Forums: Remote Application Platform (RAP)

Home » Eclipse Projects » Remote Application Platform (RAP) » RAP and OSGi Services

Thu, 22 November 2012 07:17

Eclipse User

Hi,

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,

Wim

Re: RAP and OSGi Services [message #987077 is a reply to message #986932]

Fri, 23 November 2012 05:17

Eclipse User

Hi Wim,

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?

Regards, Ralf

--
Ralf Sternberg

Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/

Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/

Re: RAP and OSGi Services [message #987079 is a reply to message #987077]

Fri, 23 November 2012 06:11

Eclipse User

Thanks for replying Ralf.

In a RAP environment, aren't there multiple UI threads?

RAP UI (1..*) --> ItemService (1) --> UserAdmin (1) --> ?session?

If I consume the ItemService "singleton" from OSGi and make a call to it from a RAP UI thread, how can the ItemService know from what UI thread the call was made?

Do you think it can be done without passing some kind of information to the OSGi service?

Best regards,

Wim

Re: RAP and OSGi Services [message #987104 is a reply to message #987079]

Fri, 23 November 2012 09:01

Eclipse User

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
(synchronously).

Rest regards, Ralf

--
Ralf Sternberg

Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/

Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/

Re: RAP and OSGi Services [message #987188 is a reply to message #986932]

Sat, 24 November 2012 05:21

Eclipse User

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.

Tom

Am 22.11.12 13:17, schrieb Wim Jongman:
> Hi,
>
> 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,
>
> Wim
>

Re: RAP and OSGi Services [message #987189 is a reply to message #987104]

Sat, 24 November 2012 05:22

Eclipse User

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
stuff anymore!

Tom

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
> (synchronously).
>
> Rest regards, Ralf
>

Re: RAP and OSGi Services [message #987306 is a reply to message #987189]

Sun, 25 November 2012 16:28

Eclipse User

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.

I believe this is discussed in one of the single-sourcing guides from EclipseSource. You should be able to get it from http://eclipsesource.com/en/info/rcp-rap-single-sourcing-guideline/

Re: RAP and OSGi Services [message #987344 is a reply to message #987306]

Mon, 26 November 2012 03:52

Eclipse User

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
2.0.

As Chris states, in RAP 1.x, you can use

UICallBack.runNonUIThreadWithFakeContext(Display, Runnable).

For 2.0, stay tuned on the New & Noteworthy pages.

Regards, Ralf

--
Ralf Sternberg

Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/

Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/

Previous Topic:	ToolItems in section#textClient gets white background instead of being transparent
Next Topic:	How to create a shell out of the screen?

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 15:32:56 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter