| Exception "Resource tree is locked" thrown in WorkspaceModifyOperation [message #166727] |
Sat, 06 December 2003 04:03  |
Eclipse User |
|
|
|
Hi everybody,
I've got a little problem concerning workspace modification and I don't
know if this is a bug or I just don't understand how to modify the
workspace correctly.
I want to create/delete some markers if a project opens/closes. For
that, I listen to project open/close via a ResourceChangeListener.
I further wrote a ChangeOperation which extends
WorkspaceModifyOperation. The ChangeOperation is called from within the
listener code to create / delete markers.
Unfortuanetly, ChangeOperation.execute() is never called. In
WorkspaceModifyOperation.run(), a ResourceException is thrown because
the resource tree is locked.
I thought WorkspaceModifyOperation takes care about these lock-problems.
Isn't this the case? So do I have to check for locks by myself? And if
yes, how can I do this best? Maybe a thread which waits until the
workspace is locked no more, then creates the markers and dies?
|
|
|
| Re: Exception "Resource tree is locked" thrown in WorkspaceModifyOperation [message #166785 is a reply to message #166727] |
Sat, 06 December 2003 13:26  |
| Eclipse User |
|
|
|
As I think now, WorkspaceModifyOperation was not written to get around
the lock-problems, but just to reduce the listener calls for events that
happen while workspace modifications.
So I assume a way to get around my problems is the one I described,
using a Thread.
If anyone has further considerations, please don't hesitate to tell.
Christian Koppen schrieb:
> Hi everybody,
>
> I've got a little problem concerning workspace modification and I don't
> know if this is a bug or I just don't understand how to modify the
> workspace correctly.
>
> I want to create/delete some markers if a project opens/closes. For
> that, I listen to project open/close via a ResourceChangeListener.
> I further wrote a ChangeOperation which extends
> WorkspaceModifyOperation. The ChangeOperation is called from within the
> listener code to create / delete markers.
>
> Unfortuanetly, ChangeOperation.execute() is never called. In
> WorkspaceModifyOperation.run(), a ResourceException is thrown because
> the resource tree is locked.
>
> I thought WorkspaceModifyOperation takes care about these lock-problems.
> Isn't this the case? So do I have to check for locks by myself? And if
> yes, how can I do this best? Maybe a thread which waits until the
> workspace is locked no more, then creates the markers and dies?
>
|
|
|
| Re: Exception "Resource tree is locked" thrown in WorkspaceModifyOperation [message #171177 is a reply to message #166727] |
Tue, 16 December 2003 14:36 |
| Eclipse User |
|
|
|
Originally posted by: John_Arthorne.oti.com_
You are not allowed to modify the workspace from within certain resource
change events, see the IResourceChangeListener javadoc for more details.
In this case the lock doesn't mean that another thread is modifying the
workspace, it just means that you're not allowed to modify it during
that callback.
--
Christian Koppen wrote:
> Hi everybody,
>
> I've got a little problem concerning workspace modification and I don't
> know if this is a bug or I just don't understand how to modify the
> workspace correctly.
>
> I want to create/delete some markers if a project opens/closes. For
> that, I listen to project open/close via a ResourceChangeListener.
> I further wrote a ChangeOperation which extends
> WorkspaceModifyOperation. The ChangeOperation is called from within the
> listener code to create / delete markers.
>
> Unfortuanetly, ChangeOperation.execute() is never called. In
> WorkspaceModifyOperation.run(), a ResourceException is thrown because
> the resource tree is locked.
>
> I thought WorkspaceModifyOperation takes care about these lock-problems.
> Isn't this the case? So do I have to check for locks by myself? And if
> yes, how can I do this best? Maybe a thread which waits until the
> workspace is locked no more, then creates the markers and dies?
>
|
|
|
Powered by
FUDForum. Page generated in 0.02291 seconds
Home