Bug #1545


Added by Alexey Demakov over 9 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Detected in build:
Published in build:


После манипуляций над требованиями в Requality Explorer в логе появляется сообщение об исключительной ситуации.
Возможно, это связано с пропаданием детей в дереве и пометкой некоторых locations в outline как несуществующих.

Надо пофиксить причину исключения.

!ENTRY org.eclipse.core.resources 4 2 2011-07-21 14:52:53.360
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
at java.util.AbstractList$Itr.checkForComodification(
at java.util.AbstractList$
at com.unitesk.requality.eclipse.Activator$1.resourceChanged(
at org.eclipse.core.internal.resources.Workspace.broadcastEvent(
at org.eclipse.core.internal.resources.Project.close(
at org.eclipse.ui.actions.CloseResourceAction.invokeOperation(
at org.eclipse.ui.actions.WorkspaceAction.execute(
at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(

Associated revisions

Revision 2222 (diff)
Added by Yuriy Shekochihin over 9 years ago

fixes #1545 i think

Revision 9850dd68 (diff)
Added by Yuriy Shekochihin over 9 years ago

fixes #1545 i think

git-svn-id: f558eac1-05b1-4da7-9ed5-5050e8a619d6

Revision 2222 (diff)
Added by Yuriy Shekochihin over 9 years ago

fixes #1545 i think



Updated by Alexey Demakov over 9 years ago

  • Target version changed from 83 to 0.12

Updated by Alexey Demakov over 9 years ago

И ещё одно:

!ENTRY org.eclipse.ui 4 4 2011-08-04 15:46:51.280
!MESSAGE java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(
at java.util.HashMap$
at com.unitesk.requality.model.TreeNodeAdapterFactory$1.getProjects(
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(
at org.eclipse.ui.internal.decorators.DecorationScheduler$


Updated by Yuriy Shekochihin over 9 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Applied in changeset r2222.


Updated by Yuriy Shekochihin over 9 years ago

  • Published in build set to 0.12.104

Updated by Viktoria Kopach over 9 years ago

  • Status changed from Resolved to Verified
  • Assignee changed from Yuriy Shekochihin to Alexey Khoroshilov

Во время проверки других тикетов было совершено много операций по манипулированию с требованиями. Такое исключение не появлялось.


Updated by Alexey Khoroshilov over 9 years ago

Вот здесь описаны рекомендации по работе с UI из не UI потоков:

Executing code from a non-UI thread

Applications that wish to call UI code from a non-UI thread must provide a Runnable that calls the UI code. The methods syncExec(Runnable) and asyncExec(Runnable) in the Display class are used to execute these runnables in the UI thread during the event loop.

  • syncExec(Runnable) should be used when the application code in the non-UI thread depends on the return value from the UI code or otherwise needs to ensure that the runnable is run to completion before returning to the thread. SWT will block the calling thread until the runnable has been run from the application's UI thread. For example, a background thread that is computing something based on a window's current size would want to synchronously run the code to get the window's size and then continue with its computations.
  • asyncExec(Runnable) should be used when the application needs to perform some UI operations, but is not dependent upon the operations being completed before continuing. For example, a background thread that updates a progress indicator or redraws a window could request the update asynchronously and continue with its processing. In this case, there is no guaranteed relationship between the timing of the background thread and the execution of the runnable.

The following code snippet demonstrates the pattern for using these methods:

   // do time-intensive computations
   // now update the UI. We don't depend on the result,
   // so use async.
   display.asyncExec (new Runnable () {
      public void run () {
         if (!myWindow.isDisposed())
            myWindow.redraw ();
   // now do more computations

It is good practice to check if your widget is disposed from within the runnable when using asyncExec. Since other things can happen in the UI thread between the call to asyncExec and the execution of your runnable, you can never be sure what state your widgets are in by the time your runnable executes.

The workbench and threads

The threading rules are very clear when you are implementing an SWT application from the ground up since you control the creation of the event loop and the decision to fork computational threads in your application.

Things get a bit more complicated when you are contributing plug-in code to the workbench. The following rules can be considered "rules of engagement" when using platform UI classes, although from release to release there may be exceptions to these rules:

  • In general, any workbench UI extensions you add to the platform will be executing in the workbench's UI thread, unless they are specifically related to threads or background jobs (such as background job progress indication).
  • If you receive an event from the workbench, it is not guaranteed that it is executing in the UI thread of the workbench. Consult the javadoc for the particular class that defines the listener or event. If there is no specific documentation discussing threading, and the class is clearly a UI-related class, you may expect that the event arrives in the UI thread of the workbench.
  • Likewise, a platform UI library should not be considered thread-safe unless it is specifically documented as such. Note that most platform UI classes dispatch listeners from the calling thread that triggered the event. Workbench and JFace API calls do not check that the caller is executing in the UI thread.This means that your plug-in may introduce a problem if you call a method that triggers an event from a non-UI thread. SWT triggers an SWTException for all API calls made from a non-UI thread. In general, avoid calling platform UI code from another thread unless the javadoc specifically allows it.
  • If your plug-in forks a computational thread or uses a workbench Job, it must use the Display asyncExec(Runnable) or syncExec(Runnable) methods when calling any API for the workbench, JFace, or SWT, unless the API specifically allows call-in from a background thread.
  • If your plug-in uses the JFace IRunnableContext interface to invoke a progress monitor and run an operation, it supplies an argument to specify whether a computational thread is forked for running the operation.

Updated by Alexey Khoroshilov over 9 years ago

  • Status changed from Verified to Closed

Also available in: Atom PDF