| Using third-party plugins in rap [message #110707] |
Wed, 29 October 2008 06:45  |
Eclipse User |
|
|
|
Originally posted by: erdal.karaca.airbus.com
I am using the datatools connectivity plugins in my test rap app.
When running, rap reports this error:
java.lang.IllegalStateException: No context available outside of the
request service lifecycle.
I have to patch a single line in order to get it up and running:
// Create a group monitor
IProgressMonitor group = Platform.getJobManager()
.createProgressGroup();
// group.beginTask(getName(), IProgressMonitor.UNKNOWN);
group.beginTask() will cause the exception thrown. Thus, I just comment it
out.
So, what is the preferred way of coping with this? If I am going to use
this patch, I must always repatch when there are new updates available of
the third-party plugins.
|
|
|
| Re: Using third-party plugins in rap [message #110826 is a reply to message #110707] |
Thu, 30 October 2008 08:04  |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
Erdal,
from my point of view there is not much you can do than patch the
sources. In some cases it might be worth to work on convincing the
third-party pug-in developers to incorporate the changes that allow
for single-sourcing.
I *absolutely* can't recommend them, but to be complete, there are
patch fragments:
http://wiki.eclipse.org/RAP/Patch_Fragments
HTH
Rüdiger
Erdal Karaca wrote:
> I am using the datatools connectivity plugins in my test rap app.
> When running, rap reports this error:
> java.lang.IllegalStateException: No context available outside of the
> request service lifecycle.
>
> I have to patch a single line in order to get it up and running:
>
> // Create a group monitor
> IProgressMonitor group = Platform.getJobManager()
> .createProgressGroup();
> // group.beginTask(getName(), IProgressMonitor.UNKNOWN);
>
> group.beginTask() will cause the exception thrown. Thus, I just
comment
> it out.
>
> So, what is the preferred way of coping with this? If I am going
to use
> this patch, I must always repatch when there are new updates
available
> of the third-party plugins.
>
>
|
|
|
|
|
| Re: Using third-party plugins in rap [message #110957 is a reply to message #110915] |
Fri, 31 October 2008 11:55 |
| Eclipse User |
|
|
|
Originally posted by: erdal.karaca.airbus.com
I reviewed the equinox aspects project and have come to the conclusion
that this will be the solution to problems which cannot be solved in time.
I.e. one could use aspects to "patch" rap code without touching it (in
aspectj this is called load-time weaving) and thus prove that a patch is
worth it to become part of the core.
For the time being, the equinox aspects project is in incubation phase,
but it is quite usefull right now.
InheritableThreadLocal sounds good. I would be interested in implementing
your solution...
stefan.hansel@tolina.de wrote:
> Ruediger,
> could this particular problem be caused by a not supported
> Display.getDefault() ?
> I didn't look at the code, but it looks like normal Jobs-API used from a
> different thread ?
> In another thread I suggested, that a Display could be stored in an
> InheritableThreadLocal to support a Default-Display in arbitary
> Worker-Threads started from the UI-Thread ...
> Maybe that could solve some integration issues with foreign-libraries ?
|
|
|
| Re: Using third-party plugins in rap [message #111017 is a reply to message #110915] |
Fri, 31 October 2008 12:33 |
| Eclipse User |
|
|
|
Originally posted by: rherrmann.innoopract.com
stefan.hansel@tolina.de wrote:
> Ruediger,
>
> could this particular problem be caused by a not supported
> Display.getDefault() ?
> I didn't look at the code, but it looks like normal Jobs-API used from a
> different thread ?
>
> In another thread I suggested, that a Display could be stored in an
> InheritableThreadLocal to support a Default-Display in arbitary
> Worker-Threads started from the UI-Thread ...
> Maybe that could solve some integration issues with foreign-libraries ?
Yes, that would probably help in many cases.
As in RAP there is a one-to-one relation between session and
display, it would rather mean to associate the thread with the
session. As a consequence, the display, session-singletons and the
like would be accessible from these threads.
On the other hand, it would then become impossible to create a
thread that is not associated to a session/display. The association
to the session would have to be removed explicitly to create a
'session-less' thread.
However, feel free to create an enhancement request to discuss and
collect ideas on this issue.
>
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.02861 seconds
] 
Search
Help
Register
Login
Home
