Home » Eclipse Projects » Remote Application Platform (RAP) » Session Id
| Session Id [message #106162] |
Wed, 24 September 2008 21:55  |
Eclipse User |
|
|
|
Originally posted by: michael.suwiryo.siemens.com
Hi,
I have question about session id in RAP. How do I get the unique identifier
of the HTTPSession in RAP either from UI Thread or Worker Thread (non UI
Thread)?
I found this static method in RWT.getSessionStore.getId() but it is not
always consistent returning the session id. Sometimes it throws
IllegalStateException.
osgi> java.lang.IllegalStateException: No context available outside of the
request service lifecycle.
at
org.eclipse.rwt.internal.service.ContextProvider.getContext( ContextProvider.java:108)
at
org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:146)
at org.eclipse.rwt.RWT.getSessionStore(RWT.java:234)
Regards,
Michael
|
|
| |
| Re: Session Id [message #106227 is a reply to message #106176] |
Thu, 25 September 2008 10:33  |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
an alternate way to access the session from within a
background/worker thread would be to use
UICallback#runNonUIThreadWithFakeContext
see the JavaDoc for more info
Stefan Roeck wrote:
> Hi,
>
> I think you can only get the SessionId from the UIThread-Context because
> internally, those session parameters are stored as a ThreadLocal object.
> If you need the SessionId in one of you worker threads you have to find
> a way to pass it from the caller (i.e. UIThread) to the worker thread.
>
> Regards,
> Stefan.
>
> Michael Suwiryo schrieb:
>> Hi,
>>
>> I have question about session id in RAP. How do I get the unique
>> identifier of the HTTPSession in RAP either from UI Thread or Worker
>> Thread (non UI Thread)?
>>
>> I found this static method in RWT.getSessionStore.getId() but it is
>> not always consistent returning the session id. Sometimes it throws
>> IllegalStateException.
>>
>> osgi> java.lang.IllegalStateException: No context available outside of
>> the request service lifecycle.
>> at
>> org.eclipse.rwt.internal.service.ContextProvider.getContext( ContextProvider.java:108)
>>
>> at
>> org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:146)
>>
>> at org.eclipse.rwt.RWT.getSessionStore(RWT.java:234)
>>
>> Regards,
>> Michael
>>
|
|
|
| Re: Session Id [message #106448 is a reply to message #106227] |
Thu, 25 September 2008 13:35 |
| Eclipse User |
|
|
|
Originally posted by: michael.suwiryo.siemens.com
Thanks for the pointer. I have another question about UICallback.
UICallback#runNonUIThreadWithFakeContext requires Display object to be
passed in as part of the method signature. In any case the call can only be
made if the current thread is UI Thread (e.g. first get the Display object
using Display.getCurrent(), and this Display must not be null). Is this
correct assumption?
My understanding is that Display.getCurrent() will return the Display object
if the current thread is UI thread, if not it will return null. On the other
hand, in RAP, Display.getDefault() is behaving just the same as
Display.getCurrent(), at least at the current RAP implementation.
Is there a plan to support a true Display.getDefault() that always return
the current default Display of the user session?
Regards,
Michael
"R
|
|
|
| Re: Session Id [message #106533 is a reply to message #106448] |
Thu, 25 September 2008 20:51 |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
Hi Michael,
please see my comments below.
HTH
Rüdiger
-----------------------------
Rüdiger Herrmann
Innoopract
http://innoopract.com
delivering eclipse technology
Michael Suwiryo wrote:
> Thanks for the pointer. I have another question about UICallback.
>
> UICallback#runNonUIThreadWithFakeContext requires Display object to be
> passed in as part of the method signature. In any case the call can only be
> made if the current thread is UI Thread (e.g. first get the Display object
> using Display.getCurrent(), and this Display must not be null). Is this
> correct assumption?
You are right in that you need to pass in the 'proper' display. That
is, the display of the session you want the background thread to be
associated with.
The call itself can be made from 'anywhere' as long as you have a
reference to a display 'around' that you can pass in (e.g.
Widget#getDisplay() or a display instance buffered elsewhere).
>
> My understanding is that Display.getCurrent() will return the Display object
> if the current thread is UI thread, if not it will return null. On the other
> hand, in RAP, Display.getDefault() is behaving just the same as
> Display.getCurrent(), at least at the current RAP implementation.
Right, getCurrent() behaves as its counterpart in SWT whereas
getDefault() does not. As you said, in RAP it currently just
delegates to getCurrent()
>
> Is there a plan to support a true Display.getDefault() that always return
> the current default Display of the user session?
In short, there is no short-term plan to implement a true
Display#getDefault().
Currently, there is a one-to-one relation between session and
display. A display in turn is the server-side representation of a
browser window/tab.
It would certainly be possible (still not an easy task) to overcome
this one-to-one relation. This could possibly allow us to have
multiple browser tabs that share one HTTP session. Maybe the content
of each tab could be represented by a distinct display.
However, it wouldn't solve the problem of calling getDefault() from
a random thread. In which case we don't know which session this
display should be associated with.
As the above is an just idea and probably only *one* possible
direction to go, do you have a use-case for getDefault()?
>
> Regards,
> Michael
>
> "Rüdiger Herrmann" <rherrmann@innoopract.com> wrote in message
> news:gbfpd3$u2r$1@build.eclipse.org...
>> an alternate way to access the session from within a background/worker
>> thread would be to use
>> UICallback#runNonUIThreadWithFakeContext
>> see the JavaDoc for more info
>>
>>
>> Stefan Roeck wrote:
>>> Hi,
>>>
>>> I think you can only get the SessionId from the UIThread-Context because
>>> internally, those session parameters are stored as a ThreadLocal object.
>>> If you need the SessionId in one of you worker threads you have to find a
>>> way to pass it from the caller (i.e. UIThread) to the worker thread.
>>>
>>> Regards,
>>> Stefan.
>>>
>>> Michael Suwiryo schrieb:
>>>> Hi,
>>>>
>>>> I have question about session id in RAP. How do I get the unique
>>>> identifier of the HTTPSession in RAP either from UI Thread or Worker
>>>> Thread (non UI Thread)?
>>>>
>>>> I found this static method in RWT.getSessionStore.getId() but it is not
>>>> always consistent returning the session id. Sometimes it throws
>>>> IllegalStateException.
>>>>
>>>> osgi> java.lang.IllegalStateException: No context available outside of
>>>> the request service lifecycle.
>>>> at
>>>> org.eclipse.rwt.internal.service.ContextProvider.getContext( ContextProvider.java:108)
>>>> at
>>>> org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:146)
>>>> at org.eclipse.rwt.RWT.getSessionStore(RWT.java:234)
>>>>
>>>> Regards,
>>>> Michael
>>>>
>
>
|
|
|
| Re: Session Id [message #106656 is a reply to message #106533] |
Mon, 29 September 2008 02:37 |
| Eclipse User |
|
|
|
Originally posted by: michael.suwiryo.siemens.com
A typical use case would be separating client side business logic code from
the GUI presentation logic.
In this scenario, the client side business logic is performed by scheduling
a job using Eclipse Jobs API. Then after the job is done, update the UI
accordingly. In RAP, we can't always rely on Display.getDefault() or
Display.getCurrent() to get the display of the session. One solution is to
keep the reference of the display locally and use that display to perform
asyncExec to execute the UI code.
Ideally, we would like to have the same capability of Display.getDefault()
in RAP so that it would make it easier to convert RCP to RAP. Otherwise, we
would have to handle the Display differently in RCP and RAP.
Regards,
Michael
"R
|
|
|
| Re: Session Id [message #107110 is a reply to message #106656] |
Tue, 30 September 2008 13:53 |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
I see the use-case but - as said - it is not out of reach but I
don't think that this is something that can be addressed soon.
As of now, the only thing to ease that aspect of single-sourcing is
to change the RCP code to adhere to the limitations of RAP (keep the
reference of the display locally).
Regards,
Rüdiger
Michael Suwiryo wrote:
> A typical use case would be separating client side business logic code from
> the GUI presentation logic.
>
> In this scenario, the client side business logic is performed by scheduling
> a job using Eclipse Jobs API. Then after the job is done, update the UI
> accordingly. In RAP, we can't always rely on Display.getDefault() or
> Display.getCurrent() to get the display of the session. One solution is to
> keep the reference of the display locally and use that display to perform
> asyncExec to execute the UI code.
>
> Ideally, we would like to have the same capability of Display.getDefault()
> in RAP so that it would make it easier to convert RCP to RAP. Otherwise, we
> would have to handle the Display differently in RCP and RAP.
>
> Regards,
> Michael
>
> "Rüdiger Herrmann" <rherrmann@innoopract.com> wrote in message
> news:gbgtkv$69u$1@build.eclipse.org...
>> Hi Michael,
>>
>> please see my comments below.
>>
>> HTH
>> Rüdiger
>> -----------------------------
>> Rüdiger Herrmann
>> Innoopract
>> http://innoopract.com
>> delivering eclipse technology
>>
>> Michael Suwiryo wrote:
>>> Thanks for the pointer. I have another question about UICallback.
>>>
>>> UICallback#runNonUIThreadWithFakeContext requires Display object to be
>>> passed in as part of the method signature. In any case the call can only
>>> be made if the current thread is UI Thread (e.g. first get the Display
>>> object using Display.getCurrent(), and this Display must not be null). Is
>>> this correct assumption?
>> You are right in that you need to pass in the 'proper' display. That is,
>> the display of the session you want the background thread to be associated
>> with.
>> The call itself can be made from 'anywhere' as long as you have a
>> reference to a display 'around' that you can pass in (e.g.
>> Widget#getDisplay() or a display instance buffered elsewhere).
>>
>>> My understanding is that Display.getCurrent() will return the Display
>>> object if the current thread is UI thread, if not it will return null. On
>>> the other hand, in RAP, Display.getDefault() is behaving just the same as
>>> Display.getCurrent(), at least at the current RAP implementation.
>> Right, getCurrent() behaves as its counterpart in SWT whereas getDefault()
>> does not. As you said, in RAP it currently just delegates to getCurrent()
>>
>>> Is there a plan to support a true Display.getDefault() that always return
>>> the current default Display of the user session?
>> In short, there is no short-term plan to implement a true
>> Display#getDefault().
>> Currently, there is a one-to-one relation between session and display. A
>> display in turn is the server-side representation of a browser window/tab.
>>
>> It would certainly be possible (still not an easy task) to overcome this
>> one-to-one relation. This could possibly allow us to have multiple browser
>> tabs that share one HTTP session. Maybe the content of each tab could be
>> represented by a distinct display.
>> However, it wouldn't solve the problem of calling getDefault() from a
>> random thread. In which case we don't know which session this display
>> should be associated with.
>>
>> As the above is an just idea and probably only *one* possible direction to
>> go, do you have a use-case for getDefault()?
>>
>>> Regards,
>>> Michael
>>>
>>> "Rüdiger Herrmann" <rherrmann@innoopract.com> wrote in message
>>> news:gbfpd3$u2r$1@build.eclipse.org...
>>>> an alternate way to access the session from within a background/worker
>>>> thread would be to use
>>>> UICallback#runNonUIThreadWithFakeContext
>>>> see the JavaDoc for more info
>>>>
>>>>
>>>> Stefan Roeck wrote:
>>>>> Hi,
>>>>>
>>>>> I think you can only get the SessionId from the UIThread-Context
>>>>> because internally, those session parameters are stored as a
>>>>> ThreadLocal object. If you need the SessionId in one of you worker
>>>>> threads you have to find a way to pass it from the caller (i.e.
>>>>> UIThread) to the worker thread.
>>>>>
>>>>> Regards,
>>>>> Stefan.
>>>>>
>>>>> Michael Suwiryo schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> I have question about session id in RAP. How do I get the unique
>>>>>> identifier of the HTTPSession in RAP either from UI Thread or Worker
>>>>>> Thread (non UI Thread)?
>>>>>>
>>>>>> I found this static method in RWT.getSessionStore.getId() but it is
>>>>>> not always consistent returning the session id. Sometimes it throws
>>>>>> IllegalStateException.
>>>>>>
>>>>>> osgi> java.lang.IllegalStateException: No context available outside of
>>>>>> the request service lifecycle.
>>>>>> at
>>>>>> org.eclipse.rwt.internal.service.ContextProvider.getContext( ContextProvider.java:108)
>>>>>> at
>>>>>> org.eclipse.rwt.internal.service.ContextProvider.getSession( ContextProvider.java:146)
>>>>>> at org.eclipse.rwt.RWT.getSessionStore(RWT.java:234)
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>
|
|
|
| Re: Session Id [message #109373 is a reply to message #106656] |
Thu, 16 October 2008 13:35 |
| Eclipse User |
|
|
|
Originally posted by: erdal.karaca.airbus.com
This will be one of the biggest problem when developers will start to
develop rap apps.
Should we file a bug report or is this already reported as a defect?
Michael Suwiryo wrote:
> A typical use case would be separating client side business logic code from
> the GUI presentation logic.
> In this scenario, the client side business logic is performed by scheduling
> a job using Eclipse Jobs API. Then after the job is done, update the UI
> accordingly. In RAP, we can't always rely on Display.getDefault() or
> Display.getCurrent() to get the display of the session. One solution is to
> keep the reference of the display locally and use that display to perform
> asyncExec to execute the UI code.
> Ideally, we would like to have the same capability of Display.getDefault()
> in RAP so that it would make it easier to convert RCP to RAP. Otherwise, we
> would have to handle the Display differently in RCP and RAP.
> Regards,
> Michael
|
|
|
| Re: Session Id [message #109397 is a reply to message #106656] |
Thu, 16 October 2008 15:27 |
|
Michael Suwiryo schrieb:
> Ideally, we would like to have the same capability of Display.getDefault()
> in RAP so that it would make it easier to convert RCP to RAP. Otherwise, we
> would have to handle the Display differently in RCP and RAP.
Not sure if that is relevant or helps, but Display.getDefault() is not
the recommended way of getting access to the Display inside the workbench.
Have a look at the JavaDoc from IWorkbench#getDisplay().
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: Session Id [message #109478 is a reply to message #109373] |
Thu, 16 October 2008 21:09 |
| Eclipse User |
|
|
|
Originally posted by: evolanakis.innoopract.com
Erdal,
I think this covers it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250696
> This will be one of the biggest problem when developers will start to
> develop rap apps.
>
> Should we file a bug report or is this already reported as a defect?
>> Ideally, we would like to have the same capability of
>> Display.getDefault() in RAP so that it would make it easier to convert
>> RCP to RAP. Otherwise, we would have to handle the Display differently
Kind regards,
Elias.
--
---
Elias Volanakis
Innoopract, Inc.
http://www.innoopract.com
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 08:00:40 GMT 2024
Powered by FUDForum. Page generated in 0.04126 seconds |
] 
Search
Help
Register
Login
Home
