[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [rap-dev] ModalContext
|
Hello Igor,
sorry that I was misleading. We currently do not have the JFace test
suite working.
But it shouldn't it be possible to "simulate" what JFace does in an
RWT-only test case?
Cheers,
Rüdiger
mail.apptech.nichost.ru wrote:
Hello
Thank you, I know about this projects. But I see that they are
patch-fragments. It allows interraction with classes from their host
plugins.
I have to get access to ModalContext class. I cannot add additional
dependence because of cycle references. What should I do?
Thank you,
Igor
-----Original Message-----
From: rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rudiger Herrmann
Sent: Friday, June 19, 2009 8:53 PM
To: RAP project development-related communication
Subject: Re: [rap-dev] ModalContext
mail.apptech.nichost.ru wrote:
Hello
One way to solve these problems could be to take the Synchronizer
class
from SWT
It is a good way, I think.
What I would appreciate most, are JUnit test cases that demonstrate
the
use case and currently fail
I'll try to do this. But is there a special project for rap jface
tests? Or I have to create new one?
Just a note, there are RWT (SWT) tests but no JFace tests.
Anyway, there are two test suites: org.eclipse.rap.rwt.test and
org.eclipse.rap.rwt.q07.test. The first test suite tests server-side
functionality, the latter mostly lifecycle-adapter code.
The split was introduced in an effort to separate the client-independent
functionality from the client-specific (qooxdoo) code. During this,
priorities shifted and we had to stop somewhere in between... That's why
there are still some open ends.
To actually run the tests you need two more projects:
* org.eclipse.rap.rwt.test.mockup
* org.eclipse.rap.rwt.testfixture
All that can be found under /cvsroot/rt/org.eclipse.rap/runtime.rwt.test
The test suites are called org.eclipse.RWTHostTestSuite and
org.eclipse.RWTQ07TestSuite
Thank you,
Igor
-----Original Message-----
From: rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx]
On Behalf Of Rudiger Herrmann
Sent: Friday, June 19, 2009 3:55 PM
To: RAP project development-related communication
Subject: Re: [rap-dev] ModalContext
Hi Igor,
as a rule of thumb, if RAP works differently than RCP, it is a bug.
To fix the bug, it should be fixed in RWT and not in the upper layers
(Workbench, JFace, etc).
I filed this bug for the issues with calling (a)syncExec( null ):
280829: [Display] calling syncExec/asyncExec(null) behaves
differently in SWT
https://bugs.eclipse.org/bugs/show_bug.cgi?id=280829
It should be relatively easy to fix this.
As far as I understand, the second and third remark are related to
synchronization. Your follow-up posting also describes synchronization
issues. Please correct me if I'm wrong.
One way to solve these problems could be to take the Synchronizer
class from SWT and use it instead of the code in UICallBackManager.
Some additions to the Synchronizer class would be necessary like
calling
UICallBackManager#sendUICallBack() from synchExec, etc.
Also sleep/readAndDispatch would need to be reworked to make use of
the Synchronizer methods/lock objects.
Then timerExec() would to need be reworked to fit into the
Synchronizer mechanism. Plus whatever I overlooked so far...
The positive aspect of this way is that we re-use the SWT
synchronization code. The downside is that a lot of the existing code
would have to be changed, which is probably more time-consuming than
just fixing the issues at hand.
What I would appreciate most, are JUnit test cases that demonstrate
the use case and currently fail. With these test cases we could then
address one issue after another.
Cheers,
Rüdiger
mail.apptech.nichost.ru wrote:
Hello
It seems that the ModalContext functionality should be reimplemented
on RAP (it is ported from RCP now).
First remark: look at the
org.eclipse.jface.operation.ModalContext.ModalContextThread.run().
There is a call: "display.asyncExec(null);". On RCP such call have a
special meaning.
This call causes display thread to wake up.
Maybe this call ("display.asyncExec(null);") should be removed from
the
org.eclipse.jface.operation.ModalContext.ModalContextThread.run() ?
Alternative maybe Display#asyncExec should be reimplemented (and also
syncExec) for the case where runnable is null?
Second remark:
There is another part of code in the
org.eclipse.jface.operation.ModalContext.ModalContextThread.run():
display.syncExec(new Runnable() {
public void run() {
// do nothing
}
});
On RAP this code causes deadlocks with
org.eclipse.jface.operation.ModalContext.ModalContextThread.block()
method.
Moreover, there is a problem with
org.eclipse.rwt.internal.lifecycle.UICallBackManager.SyncRunnable and
ModalContext. As you know, SyncRunnable has a block() method, wich
blocks the thread that called
org.eclipse.rwt.internal.lifecycle.UICallBackManager.addSync(Display,
Runnable) method. The blocked thread will wait on special lock object
until the notification from other thread (with should call
SyncRunnable#run method). But when you are using ModalContext the
other thread will blocked on runnablesLock.
I think the problem in the
org.eclipse.rwt.internal.lifecycle.UICallBackManager.addSync(Display,
Runnable) method.
Third remark:
// Make sure that all events in the asynchronous event queue // are
dispatched.
display.syncExec(new Runnable() {
public void run() {
// do nothing
}
});
This code do not the things that declared in comments.
Last remark: "display.asyncExec(null);" can be implemented correctly,
but you have to place additional synchronization string in
org.eclipse.jface.operation.ModalContext.ModalContextThread.run() to
prevent ending of execution
org.eclipse.jface.operation.ModalContext.ModalContextThread.run()
before
display.sleep() occures in
org.eclipse.jface.operation.ModalContext.ModalContextThread.block()
method.
Place
synchronized (display.getThread()) {
}
before
// Stop event dispatching
continueEventDispatching = false;
The display.getThread() returns UIThread instance. So it will be
locked until the switchThread notification from display.sleap() method.
Thank you, Igor
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev
_______________________________________________
rap-dev mailing list
rap-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rap-dev