Home » Modeling » EMF » Setting ModelElement values from a non-UI thread
| Setting ModelElement values from a non-UI thread [message #430964] |
Sun, 21 June 2009 23:20  |
Eclipse User |
|
|
|
Originally posted by: pfeiffec.in.tum.de
Hi,
I encountered some difficulties trying to set a ModelElement value from
a non-UI thread, resulting in "Invalid Thread Access" exceptions.
Now, the circumstances are as follows:
There exists a client and a server. The client uploads files to a
server, and then sets the FileAttachment (subtype of ModelElement)
values. The upload itself is executed within a Job (Eclipse Worker
Thread), which means that the values are set from the Eclipse and not
from the UI-thread.
public abstract class FileTransferJob extends Job ...
protected void setAttributes() {
TransactionalEditingDomain domain =
TransactionalEditingDomain.Registry.INSTANCE
.getEditingDomain("...");
domain.getCommandStack().execute(new RecordingCommand(domain) {
@Override
protected void doExecute() {
if (fileAttachment.getFileID() == null ||
fileAttachment.getFileID().equals("")
|| Integer.parseInt(fileAttachment.getFileID()) <=
fileInformation.getFileVersion()) {
fileAttachment.setFileName(fileInformation.getFileName());
fileAttachment.setFileID("" + fileInformation.getFileVersion());
fileAttachment.setFileSize(fileInformation.getFileSize());
}
}
});
}
As I cannot access any Display class to perform Display.syncExec() for
the very method that sets the values, (which would have solved the
problem), I started looking for other solutions.
Would it be a good idea to subclass the
EditingDomainEObjectObservableValue and override the doSetValue() method
to make use of the Display.syncExec()-method?
@Override
protected void doSetValue(Object value)
{
Command command = SetCommand.create(domain, eObject,
eStructuralFeature, value);
domain.getCommandStack().execute(command);
}
I do hope someone finds the time to answer this question, I have so far
failed miserably ;)
Cheers,
Carl
|
|
|
| Re: Setting ModelElement values from a non-UI thread [message #430965 is a reply to message #430964] |
Mon, 22 June 2009 07:36  |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi Carl,
And where from would you get the display in the observable? Anyways
Eclipse-Databinding should have solved the problem for you (syncing
between different threads is done by the Realms).
Can you give us a stacktrace?
The easiest solution BTW is to use Display.geDefault() which gives you
access to the display from everywhere but as menntionned it should not
be a problem when using Eclipse-Databinding.
Tom
Carl Pfeiffer schrieb:
> Hi,
>
> I encountered some difficulties trying to set a ModelElement value from
> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
>
> Now, the circumstances are as follows:
>
> There exists a client and a server. The client uploads files to a
> server, and then sets the FileAttachment (subtype of ModelElement)
> values. The upload itself is executed within a Job (Eclipse Worker
> Thread), which means that the values are set from the Eclipse and not
> from the UI-thread.
>
> public abstract class FileTransferJob extends Job ...
>
> protected void setAttributes() {
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Registry.INSTANCE
> .getEditingDomain("...");
> domain.getCommandStack().execute(new RecordingCommand(domain) {
> @Override
> protected void doExecute() {
> if (fileAttachment.getFileID() == null ||
> fileAttachment.getFileID().equals("")
> || Integer.parseInt(fileAttachment.getFileID()) <=
> fileInformation.getFileVersion()) {
>
> fileAttachment.setFileName(fileInformation.getFileName());
> fileAttachment.setFileID("" +
> fileInformation.getFileVersion());
>
> fileAttachment.setFileSize(fileInformation.getFileSize());
> }
> }
> });
> }
>
> As I cannot access any Display class to perform Display.syncExec() for
> the very method that sets the values, (which would have solved the
> problem), I started looking for other solutions.
>
> Would it be a good idea to subclass the
> EditingDomainEObjectObservableValue and override the doSetValue() method
> to make use of the Display.syncExec()-method?
>
> @Override
> protected void doSetValue(Object value)
> {
> Command command = SetCommand.create(domain, eObject,
> eStructuralFeature, value);
> domain.getCommandStack().execute(command);
> }
>
> I do hope someone finds the time to answer this question, I have so far
> failed miserably ;)
>
> Cheers,
> Carl
|
|
|
| Re: Setting ModelElement values from a non-UI thread [message #430967 is a reply to message #430965] |
Mon, 22 June 2009 08:57 |
| Eclipse User |
|
|
|
Originally posted by: pfeiffec.in.tum.de
Hi Tom,
The Observable is located in a plugin without restrictions to the
Display-class. The FileTransferJob classes are not, which would be the
reason why I can only use Display in the Observable.
As to the DataBinding, that is what I did and that is where it fails.
IObservableValue model =
EMFEditObservables.observeValue(getEditingDomain(), getModelElement(),
attribute);
EMFDataBindingContext dbc = new EMFDataBindingContext();
dbc.bindValue(SWTObservables.observeText(fileName, SWT.FocusOut),
model, null, null);
That is where I bind the fileName value to the ModelElement.
The StackTrace:
org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:3884)
at org.eclipse.swt.SWT.error(SWT.java:3799)
at org.eclipse.swt.SWT.error(SWT.java:3770)
at org.eclipse.swt.widgets.Widget.error(Widget.java:463)
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:355)
at org.eclipse.swt.widgets.Control.redraw(Control.java:2140)
at org.eclipse.ui.forms.widgets.Hyperlink.setText(Hyperlink.jav a:183)
at
org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkContr ol$1.labelProviderChanged(MELinkControl.java:70)
at
org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider .fireLabelProviderChanged(AdapterFactoryLabelProvider.java:6 73)
at
org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkLabel Provider.notifyChanged(MELinkLabelProvider.java:36)
at
org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChang ed(ChangeNotifier.java:51)
at
org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNot ifyChanged(ComposedAdapterFactory.java:475)
at
org.unicase.model.attachment.provider.AttachmentItemProvider AdapterFactory.fireNotifyChanged(AttachmentItemProviderAdapt erFactory.java:204)
at
org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotify Changed(ItemProviderAdapter.java:220)
at
org.unicase.model.attachment.provider.FileAttachmentItemProv ider.notifyChanged(FileAttachmentItemProvider.java:155)
at
org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
at
org.unicase.model.attachment.impl.FileAttachmentImpl.setFile Name(FileAttachmentImpl.java:189)
at
org.unicase.model.attachment.impl.FileAttachmentImpl.eUnset( FileAttachmentImpl.java:366)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eUnset(BasicEObj ectImpl.java:1156)
at
org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:516)
at
org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:484)
at
org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl y(ChangeDescriptionImpl.java:297)
at
org.eclipse.emf.transaction.util.CompositeChangeDescription. apply(CompositeChangeDescription.java:104)
at
org.eclipse.emf.transaction.impl.TransactionImpl.doRollback( TransactionImpl.java:570)
at
org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:404)
at
org.eclipse.emf.transaction.impl.TransactionalCommandStackIm pl.doExecute(TransactionalCommandStackImpl.java:70)
at
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:165)
at
org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:219)
at
org.unicase.workspace.filetransfer.FileTransferJob.setAttrib utes(FileTransferJob.java:131)
at
org.unicase.workspace.filetransfer.FileUploadJob.run(FileUpl oadJob.java:62)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Cheers,
Carl
Tom Schindl wrote:
> Hi Carl,
>
> And where from would you get the display in the observable? Anyways
> Eclipse-Databinding should have solved the problem for you (syncing
> between different threads is done by the Realms).
>
> Can you give us a stacktrace?
>
> The easiest solution BTW is to use Display.geDefault() which gives you
> access to the display from everywhere but as menntionned it should not
> be a problem when using Eclipse-Databinding.
>
> Tom
>
> Carl Pfeiffer schrieb:
>> Hi,
>>
>> I encountered some difficulties trying to set a ModelElement value from
>> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
>>
>> Now, the circumstances are as follows:
>>
>> There exists a client and a server. The client uploads files to a
>> server, and then sets the FileAttachment (subtype of ModelElement)
>> values. The upload itself is executed within a Job (Eclipse Worker
>> Thread), which means that the values are set from the Eclipse and not
>> from the UI-thread.
>>
>> public abstract class FileTransferJob extends Job ...
>>
>> protected void setAttributes() {
>> TransactionalEditingDomain domain =
>> TransactionalEditingDomain.Registry.INSTANCE
>> .getEditingDomain("...");
>> domain.getCommandStack().execute(new RecordingCommand(domain) {
>> @Override
>> protected void doExecute() {
>> if (fileAttachment.getFileID() == null ||
>> fileAttachment.getFileID().equals("")
>> || Integer.parseInt(fileAttachment.getFileID()) <=
>> fileInformation.getFileVersion()) {
>>
>> fileAttachment.setFileName(fileInformation.getFileName());
>> fileAttachment.setFileID("" +
>> fileInformation.getFileVersion());
>>
>> fileAttachment.setFileSize(fileInformation.getFileSize());
>> }
>> }
>> });
>> }
>>
>> As I cannot access any Display class to perform Display.syncExec() for
>> the very method that sets the values, (which would have solved the
>> problem), I started looking for other solutions.
>>
>> Would it be a good idea to subclass the
>> EditingDomainEObjectObservableValue and override the doSetValue() method
>> to make use of the Display.syncExec()-method?
>>
>> @Override
>> protected void doSetValue(Object value)
>> {
>> Command command = SetCommand.create(domain, eObject,
>> eStructuralFeature, value);
>> domain.getCommandStack().execute(command);
>> }
>>
>> I do hope someone finds the time to answer this question, I have so far
>> failed miserably ;)
>>
>> Cheers,
>> Carl
|
|
|
| Re: Setting ModelElement values from a non-UI thread [message #430969 is a reply to message #430967] |
Mon, 22 June 2009 09:12 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi Carl,
Obviously it is not the Databinding at least I didn't spot a single
method in the stack you are presenting.
The stack you are presenting points to EMF-Edit stuff which is not
syncing calls from None-UI-Threads. IMHO the fix has to be in
"MELinkControl.java:70" where you need to check if you are on the
display thread before setting the text.
Tom
Carl Pfeiffer schrieb:
> Hi Tom,
>
> The Observable is located in a plugin without restrictions to the
> Display-class. The FileTransferJob classes are not, which would be the
> reason why I can only use Display in the Observable.
>
> As to the DataBinding, that is what I did and that is where it fails.
>
> IObservableValue model =
> EMFEditObservables.observeValue(getEditingDomain(), getModelElement(),
> attribute);
> EMFDataBindingContext dbc = new EMFDataBindingContext();
> dbc.bindValue(SWTObservables.observeText(fileName,
> SWT.FocusOut), model, null, null);
>
> That is where I bind the fileName value to the ModelElement.
>
> The StackTrace:
>
> org.eclipse.swt.SWTException: Invalid thread access
> at org.eclipse.swt.SWT.error(SWT.java:3884)
> at org.eclipse.swt.SWT.error(SWT.java:3799)
> at org.eclipse.swt.SWT.error(SWT.java:3770)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:463)
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:355)
> at org.eclipse.swt.widgets.Control.redraw(Control.java:2140)
> at org.eclipse.ui.forms.widgets.Hyperlink.setText(Hyperlink.jav a:183)
> at
> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkContr ol$1.labelProviderChanged(MELinkControl.java:70)
>
> at
> org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider .fireLabelProviderChanged(AdapterFactoryLabelProvider.java:6 73)
>
> at
> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkLabel Provider.notifyChanged(MELinkLabelProvider.java:36)
>
> at
> org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChang ed(ChangeNotifier.java:51)
>
> at
> org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNot ifyChanged(ComposedAdapterFactory.java:475)
>
> at
> org.unicase.model.attachment.provider.AttachmentItemProvider AdapterFactory.fireNotifyChanged(AttachmentItemProviderAdapt erFactory.java:204)
>
> at
> org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotify Changed(ItemProviderAdapter.java:220)
>
> at
> org.unicase.model.attachment.provider.FileAttachmentItemProv ider.notifyChanged(FileAttachmentItemProvider.java:155)
>
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
>
> at
> org.unicase.model.attachment.impl.FileAttachmentImpl.setFile Name(FileAttachmentImpl.java:189)
>
> at
> org.unicase.model.attachment.impl.FileAttachmentImpl.eUnset( FileAttachmentImpl.java:366)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eUnset(BasicEObj ectImpl.java:1156)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:516)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:484)
>
> at
> org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl y(ChangeDescriptionImpl.java:297)
>
> at
> org.eclipse.emf.transaction.util.CompositeChangeDescription. apply(CompositeChangeDescription.java:104)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.doRollback( TransactionImpl.java:570)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:404)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalCommandStackIm pl.doExecute(TransactionalCommandStackImpl.java:70)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:165)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:219)
>
> at
> org.unicase.workspace.filetransfer.FileTransferJob.setAttrib utes(FileTransferJob.java:131)
>
> at
> org.unicase.workspace.filetransfer.FileUploadJob.run(FileUpl oadJob.java:62)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>
>
> Cheers,
> Carl
>
> Tom Schindl wrote:
>> Hi Carl,
>>
>> And where from would you get the display in the observable? Anyways
>> Eclipse-Databinding should have solved the problem for you (syncing
>> between different threads is done by the Realms).
>>
>> Can you give us a stacktrace?
>>
>> The easiest solution BTW is to use Display.geDefault() which gives you
>> access to the display from everywhere but as menntionned it should not
>> be a problem when using Eclipse-Databinding.
>>
>> Tom
>>
>> Carl Pfeiffer schrieb:
>>> Hi,
>>>
>>> I encountered some difficulties trying to set a ModelElement value from
>>> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
>>>
>>> Now, the circumstances are as follows:
>>>
>>> There exists a client and a server. The client uploads files to a
>>> server, and then sets the FileAttachment (subtype of ModelElement)
>>> values. The upload itself is executed within a Job (Eclipse Worker
>>> Thread), which means that the values are set from the Eclipse and not
>>> from the UI-thread.
>>>
>>> public abstract class FileTransferJob extends Job ...
>>>
>>> protected void setAttributes() {
>>> TransactionalEditingDomain domain =
>>> TransactionalEditingDomain.Registry.INSTANCE
>>> .getEditingDomain("...");
>>> domain.getCommandStack().execute(new RecordingCommand(domain) {
>>> @Override
>>> protected void doExecute() {
>>> if (fileAttachment.getFileID() == null ||
>>> fileAttachment.getFileID().equals("")
>>> || Integer.parseInt(fileAttachment.getFileID()) <=
>>> fileInformation.getFileVersion()) {
>>>
>>> fileAttachment.setFileName(fileInformation.getFileName());
>>> fileAttachment.setFileID("" +
>>> fileInformation.getFileVersion());
>>>
>>> fileAttachment.setFileSize(fileInformation.getFileSize());
>>> }
>>> }
>>> });
>>> }
>>>
>>> As I cannot access any Display class to perform Display.syncExec() for
>>> the very method that sets the values, (which would have solved the
>>> problem), I started looking for other solutions.
>>>
>>> Would it be a good idea to subclass the
>>> EditingDomainEObjectObservableValue and override the doSetValue() method
>>> to make use of the Display.syncExec()-method?
>>>
>>> @Override
>>> protected void doSetValue(Object value)
>>> {
>>> Command command = SetCommand.create(domain, eObject,
>>> eStructuralFeature, value);
>>> domain.getCommandStack().execute(command);
>>> }
>>>
>>> I do hope someone finds the time to answer this question, I have so far
>>> failed miserably ;)
>>>
>>> Cheers,
>>> Carl
|
|
|
| Re: Setting ModelElement values from a non-UI thread [message #430977 is a reply to message #430969] |
Mon, 22 June 2009 12:26 |
|
--=-AcMmK65tO3nRZf8LlPjB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Carl,
In addition to Tom's comments, it is worth noting that the invalid
thread-access is masking a transaction roll-back, which appears to be
caused by validation failure on the attempt to commit. That will be
something to look into. Of course, it's also possible that the
transaction is trying to roll-back because of an uncaught exception such
as ... you guessed it ... invalid thread-access.
Cheers,
Christian
On Mon, 2009-06-22 at 11:12 +0200, Tom Schindl wrote:
> Hi Carl,
>
> Obviously it is not the Databinding at least I didn't spot a single
> method in the stack you are presenting.
>
> The stack you are presenting points to EMF-Edit stuff which is not
> syncing calls from None-UI-Threads. IMHO the fix has to be in
> "MELinkControl.java:70" where you need to check if you are on the
> display thread before setting the text.
>
> Tom
>
> Carl Pfeiffer schrieb:
> > Hi Tom,
> >
> > The Observable is located in a plugin without restrictions to the
> > Display-class. The FileTransferJob classes are not, which would be the
> > reason why I can only use Display in the Observable.
> >
> > As to the DataBinding, that is what I did and that is where it fails.
> >
> > IObservableValue model =
> > EMFEditObservables.observeValue(getEditingDomain(), getModelElement(),
> > attribute);
> > EMFDataBindingContext dbc = new EMFDataBindingContext();
> > dbc.bindValue(SWTObservables.observeText(fileName,
> > SWT.FocusOut), model, null, null);
> >
> > That is where I bind the fileName value to the ModelElement.
> >
> > The StackTrace:
> >
> > org.eclipse.swt.SWTException: Invalid thread access
> > at org.eclipse.swt.SWT.error(SWT.java:3884)
> > at org.eclipse.swt.SWT.error(SWT.java:3799)
> > at org.eclipse.swt.SWT.error(SWT.java:3770)
> > at org.eclipse.swt.widgets.Widget.error(Widget.java:463)
> > at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:355)
> > at org.eclipse.swt.widgets.Control.redraw(Control.java:2140)
> > at org.eclipse.ui.forms.widgets.Hyperlink.setText(Hyperlink.jav a:183)
> > at
> > org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkContr ol$1.labelProviderChanged(MELinkControl.java:70)
> >
> > at
> > org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider .fireLabelProviderChanged(AdapterFactoryLabelProvider.java:6 73)
> >
> > at
> > org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkLabel Provider.notifyChanged(MELinkLabelProvider.java:36)
> >
> > at
> > org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChang ed(ChangeNotifier.java:51)
> >
> > at
> > org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNot ifyChanged(ComposedAdapterFactory.java:475)
> >
> > at
> > org.unicase.model.attachment.provider.AttachmentItemProvider AdapterFactory.fireNotifyChanged(AttachmentItemProviderAdapt erFactory.java:204)
> >
> > at
> > org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotify Changed(ItemProviderAdapter.java:220)
> >
> > at
> > org.unicase.model.attachment.provider.FileAttachmentItemProv ider.notifyChanged(FileAttachmentItemProvider.java:155)
> >
> > at
> > org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
> >
> > at
> > org.unicase.model.attachment.impl.FileAttachmentImpl.setFile Name(FileAttachmentImpl.java:189)
> >
> > at
> > org.unicase.model.attachment.impl.FileAttachmentImpl.eUnset( FileAttachmentImpl.java:366)
> >
> > at
> > org.eclipse.emf.ecore.impl.BasicEObjectImpl.eUnset(BasicEObj ectImpl.java:1156)
> >
> > at
> > org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:516)
> >
> > at
> > org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:484)
> >
> > at
> > org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl y(ChangeDescriptionImpl.java:297)
> >
> > at
> > org.eclipse.emf.transaction.util.CompositeChangeDescription. apply(CompositeChangeDescription.java:104)
> >
> > at
> > org.eclipse.emf.transaction.impl.TransactionImpl.doRollback( TransactionImpl.java:570)
> >
> > at
> > org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:404)
> >
> > at
> > org.eclipse.emf.transaction.impl.TransactionalCommandStackIm pl.doExecute(TransactionalCommandStackImpl.java:70)
> >
> > at
> > org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:165)
> >
> > at
> > org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:219)
> >
> > at
> > org.unicase.workspace.filetransfer.FileTransferJob.setAttrib utes(FileTransferJob.java:131)
> >
> > at
> > org.unicase.workspace.filetransfer.FileUploadJob.run(FileUpl oadJob.java:62)
> > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> >
> >
> > Cheers,
> > Carl
> >
> > Tom Schindl wrote:
> >> Hi Carl,
> >>
> >> And where from would you get the display in the observable? Anyways
> >> Eclipse-Databinding should have solved the problem for you (syncing
> >> between different threads is done by the Realms).
> >>
> >> Can you give us a stacktrace?
> >>
> >> The easiest solution BTW is to use Display.geDefault() which gives you
> >> access to the display from everywhere but as menntionned it should not
> >> be a problem when using Eclipse-Databinding.
> >>
> >> Tom
> >>
> >> Carl Pfeiffer schrieb:
> >>> Hi,
> >>>
> >>> I encountered some difficulties trying to set a ModelElement value from
> >>> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
> >>>
> >>> Now, the circumstances are as follows:
> >>>
> >>> There exists a client and a server. The client uploads files to a
> >>> server, and then sets the FileAttachment (subtype of ModelElement)
> >>> values. The upload itself is executed within a Job (Eclipse Worker
> >>> Thread), which means that the values are set from the Eclipse and not
> >>> from the UI-thread.
> >>>
> >>> public abstract class FileTransferJob extends Job ...
> >>>
> >>> protected void setAttributes() {
> >>> TransactionalEditingDomain domain =
> >>> TransactionalEditingDomain.Registry.INSTANCE
> >>> .getEditingDomain("...");
> >>> domain.getCommandStack().execute(new RecordingCommand(domain) {
> >>> @Override
> >>> protected void doExecute() {
> >>> if (fileAttachment.getFileID() == null ||
> >>> fileAttachment.getFileID().equals("")
> >>> || Integer.parseInt(fileAttachment.getFileID()) <=
> >>> fileInformation.getFileVersion()) {
> >>>
> >>> fileAttachment.setFileName(fileInformation.getFileName());
> >>> fileAttachment.setFileID("" +
> >>> fileInformation.getFileVersion());
> >>>
> >>> fileAttachment.setFileSize(fileInformation.getFileSize());
> >>> }
> >>> }
> >>> });
> >>> }
> >>>
> >>> As I cannot access any Display class to perform Display.syncExec() for
> >>> the very method that sets the values, (which would have solved the
> >>> problem), I started looking for other solutions.
> >>>
> >>> Would it be a good idea to subclass the
> >>> EditingDomainEObjectObservableValue and override the doSetValue() method
> >>> to make use of the Display.syncExec()-method?
> >>>
> >>> @Override
> >>> protected void doSetValue(Object value)
> >>> {
> >>> Command command = SetCommand.create(domain, eObject,
> >>> eStructuralFeature, value);
> >>> domain.getCommandStack().execute(command);
> >>> }
> >>>
> >>> I do hope someone finds the time to answer this question, I have so far
> >>> failed miserably ;)
> >>>
> >>> Cheers,
> >>> Carl
--=-AcMmK65tO3nRZf8LlPjB
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Carl,<BR>
<BR>
In addition to Tom's comments, it is worth noting that the invalid thread-access is masking a transaction roll-back, which appears to be caused by validation failure on the attempt to commit. That will be something to look into. Of course, it's also possible that the transaction is trying to roll-back because of an uncaught exception such as ... you guessed it ... invalid thread-access.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Mon, 2009-06-22 at 11:12 +0200, Tom Schindl wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Carl,
Obviously it is not the Databinding at least I didn't spot a single
method in the stack you are presenting.
The stack you are presenting points to EMF-Edit stuff which is not
syncing calls from None-UI-Threads. IMHO the fix has to be in
"MELinkControl.java:70" where you need to check if you are on the
display thread before setting the text.
Tom
Carl Pfeiffer schrieb:
> Hi Tom,
>
> The Observable is located in a plugin without restrictions to the
> Display-class. The FileTransferJob classes are not, which would be the
> reason why I can only use Display in the Observable.
>
> As to the DataBinding, that is what I did and that is where it fails.
>
> IObservableValue model =
> EMFEditObservables.observeValue(getEditingDomain(), getModelElement(),
> attribute);
> EMFDataBindingContext dbc = new EMFDataBindingContext();
> dbc.bindValue(SWTObservables.observeText(fileName,
> SWT.FocusOut), model, null, null);
>
> That is where I bind the fileName value to the ModelElement.
>
> The StackTrace:
>
> org.eclipse.swt.SWTException: Invalid thread access
> at org.eclipse.swt.SWT.error(SWT.java:3884)
> at org.eclipse.swt.SWT.error(SWT.java:3799)
> at org.eclipse.swt.SWT.error(SWT.java:3770)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:463)
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:355)
> at org.eclipse.swt.widgets.Control.redraw(Control.java:2140)
> at org.eclipse.ui.forms.widgets.Hyperlink.setText(Hyperlink.jav a:183)
> at
> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkContr ol$1.labelProviderChanged(MELinkControl.java:70)
>
> at
> org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider .fireLabelProviderChanged(AdapterFactoryLabelProvider.java:6 73)
>
> at
> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkLabel Provider.notifyChanged(MELinkLabelProvider.java:36)
>
> at
> org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChang ed(ChangeNotifier.java:51)
>
> at
> org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNot ifyChanged(ComposedAdapterFactory.java:475)
>
> at
> org.unicase.model.attachment.provider.AttachmentItemProvider AdapterFactory.fireNotifyChanged(AttachmentItemProviderAdapt erFactory.java:204)
>
> at
> org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotify Changed(ItemProviderAdapter.java:220)
>
> at
> org.unicase.model.attachment.provider.FileAttachmentItemProv ider.notifyChanged(FileAttachmentItemProvider.java:155)
>
> at
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
>
> at
> org.unicase.model.attachment.impl.FileAttachmentImpl.setFile Name(FileAttachmentImpl.java:189)
>
> at
> org.unicase.model.attachment.impl.FileAttachmentImpl.eUnset( FileAttachmentImpl.java:366)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eUnset(BasicEObj ectImpl.java:1156)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:516)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:484)
>
> at
> org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl y(ChangeDescriptionImpl.java:297)
>
> at
> org.eclipse.emf.transaction.util.CompositeChangeDescription. apply(CompositeChangeDescription.java:104)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.doRollback( TransactionImpl.java:570)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:404)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalCommandStackIm pl.doExecute(TransactionalCommandStackImpl.java:70)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:165)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:219)
>
> at
> org.unicase.workspace.filetransfer.FileTransferJob.setAttrib utes(FileTransferJob.java:131)
>
> at
> org.unicase.workspace.filetransfer.FileUploadJob.run(FileUpl oadJob.java:62)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>
>
> Cheers,
> Carl
>
> Tom Schindl wrote:
>> Hi Carl,
>>
>> And where from would you get the display in the observable? Anyways
>> Eclipse-Databinding should have solved the problem for you (syncing
>> between different threads is done by the Realms).
>>
>> Can you give us a stacktrace?
>>
>> The easiest solution BTW is to use Display.geDefault() which gives you
>> access to the display from everywhere but as menntionned it should not
>> be a problem when using Eclipse-Databinding.
>>
>> Tom
>>
>> Carl Pfeiffer schrieb:
>>> Hi,
>>>
>>> I encountered some difficulties trying to set a ModelElement value from
>>> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
>>>
>>> Now, the circumstances are as follows:
>>>
>>> There exists a client and a server. The client uploads files to a
>>> server, and then sets the FileAttachment (subtype of ModelElement)
>>> values. The upload itself is executed within a Job (Eclipse Worker
>>> Thread), which means that the values are set from the Eclipse and not
>>> from the UI-thread.
>>>
>>> public abstract class FileTransferJob extends Job ...
>>>
>>> protected void setAttributes() {
>>> TransactionalEditingDomain domain =
>>> TransactionalEditingDomain.Registry.INSTANCE
>>> .getEditingDomain("...");
>>> domain.getCommandStack().execute(new RecordingCommand(domain) {
>>> @Override
>>> protected void doExecute() {
>>> if (fileAttachment.getFileID() == null ||
>>> fileAttachment.getFileID().equals("")
>>> || Integer.parseInt(fileAttachment.getFileID()) <=
>>> fileInformation.getFileVersion()) {
>>>
>>> fileAttachment.setFileName(fileInformation.getFileName());
>>> fileAttachment.setFileID("" +
>>> fileInformation.getFileVersion());
>>>
>>> fileAttachment.setFileSize(fileInformation.getFileSize());
>>> }
>>> }
>>> });
>>> }
>>>
>>> As I cannot access any Display class to perform Display.syncExec() for
>>> the very method that sets the values, (which would have solved the
>>> problem), I started looking for other solutions.
>>>
>>> Would it be a good idea to subclass the
>>> EditingDomainEObjectObservableValue and override the doSetValue() method
>>> to make use of the Display.syncExec()-method?
>>>
>>> @Override
>>> protected void doSetValue(Object value)
>>> {
>>> Command command = SetCommand.create(domain, eObject,
>>> eStructuralFeature, value);
>>> domain.getCommandStack().execute(command);
>>> }
>>>
>>> I do hope someone finds the time to answer this question, I have so far
>>> failed miserably ;)
>>>
>>> Cheers,
>>> Carl
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-AcMmK65tO3nRZf8LlPjB--
|
|
|
| Re: Setting ModelElement values from a non-UI thread [message #430984 is a reply to message #430969] |
Tue, 23 June 2009 00:01 |
| Eclipse User |
|
|
|
Originally posted by: pfeiffec.in.tum.de
Hi Tom,
Right you are. Thanks for your help! I hope I wasn't bothering with too
"easy" stuff, EMF is very new to me.
Cheers,
Carl
Tom Schindl wrote:
> Hi Carl,
>
> Obviously it is not the Databinding at least I didn't spot a single
> method in the stack you are presenting.
>
> The stack you are presenting points to EMF-Edit stuff which is not
> syncing calls from None-UI-Threads. IMHO the fix has to be in
> "MELinkControl.java:70" where you need to check if you are on the
> display thread before setting the text.
>
> Tom
>
> Carl Pfeiffer schrieb:
>> Hi Tom,
>>
>> The Observable is located in a plugin without restrictions to the
>> Display-class. The FileTransferJob classes are not, which would be the
>> reason why I can only use Display in the Observable.
>>
>> As to the DataBinding, that is what I did and that is where it fails.
>>
>> IObservableValue model =
>> EMFEditObservables.observeValue(getEditingDomain(), getModelElement(),
>> attribute);
>> EMFDataBindingContext dbc = new EMFDataBindingContext();
>> dbc.bindValue(SWTObservables.observeText(fileName,
>> SWT.FocusOut), model, null, null);
>>
>> That is where I bind the fileName value to the ModelElement.
>>
>> The StackTrace:
>>
>> org.eclipse.swt.SWTException: Invalid thread access
>> at org.eclipse.swt.SWT.error(SWT.java:3884)
>> at org.eclipse.swt.SWT.error(SWT.java:3799)
>> at org.eclipse.swt.SWT.error(SWT.java:3770)
>> at org.eclipse.swt.widgets.Widget.error(Widget.java:463)
>> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:355)
>> at org.eclipse.swt.widgets.Control.redraw(Control.java:2140)
>> at org.eclipse.ui.forms.widgets.Hyperlink.setText(Hyperlink.jav a:183)
>> at
>> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkContr ol$1.labelProviderChanged(MELinkControl.java:70)
>>
>> at
>> org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider .fireLabelProviderChanged(AdapterFactoryLabelProvider.java:6 73)
>>
>> at
>> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkLabel Provider.notifyChanged(MELinkLabelProvider.java:36)
>>
>> at
>> org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChang ed(ChangeNotifier.java:51)
>>
>> at
>> org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNot ifyChanged(ComposedAdapterFactory.java:475)
>>
>> at
>> org.unicase.model.attachment.provider.AttachmentItemProvider AdapterFactory.fireNotifyChanged(AttachmentItemProviderAdapt erFactory.java:204)
>>
>> at
>> org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotify Changed(ItemProviderAdapter.java:220)
>>
>> at
>> org.unicase.model.attachment.provider.FileAttachmentItemProv ider.notifyChanged(FileAttachmentItemProvider.java:155)
>>
>> at
>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
>>
>> at
>> org.unicase.model.attachment.impl.FileAttachmentImpl.setFile Name(FileAttachmentImpl.java:189)
>>
>> at
>> org.unicase.model.attachment.impl.FileAttachmentImpl.eUnset( FileAttachmentImpl.java:366)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eUnset(BasicEObj ectImpl.java:1156)
>>
>> at
>> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:516)
>>
>> at
>> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:484)
>>
>> at
>> org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl y(ChangeDescriptionImpl.java:297)
>>
>> at
>> org.eclipse.emf.transaction.util.CompositeChangeDescription. apply(CompositeChangeDescription.java:104)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionImpl.doRollback( TransactionImpl.java:570)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:404)
>>
>> at
>> org.eclipse.emf.transaction.impl.TransactionalCommandStackIm pl.doExecute(TransactionalCommandStackImpl.java:70)
>>
>> at
>> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:165)
>>
>> at
>> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:219)
>>
>> at
>> org.unicase.workspace.filetransfer.FileTransferJob.setAttrib utes(FileTransferJob.java:131)
>>
>> at
>> org.unicase.workspace.filetransfer.FileUploadJob.run(FileUpl oadJob.java:62)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>>
>>
>> Cheers,
>> Carl
>>
>> Tom Schindl wrote:
>>> Hi Carl,
>>>
>>> And where from would you get the display in the observable? Anyways
>>> Eclipse-Databinding should have solved the problem for you (syncing
>>> between different threads is done by the Realms).
>>>
>>> Can you give us a stacktrace?
>>>
>>> The easiest solution BTW is to use Display.geDefault() which gives you
>>> access to the display from everywhere but as menntionned it should not
>>> be a problem when using Eclipse-Databinding.
>>>
>>> Tom
>>>
>>> Carl Pfeiffer schrieb:
>>>> Hi,
>>>>
>>>> I encountered some difficulties trying to set a ModelElement value from
>>>> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
>>>>
>>>> Now, the circumstances are as follows:
>>>>
>>>> There exists a client and a server. The client uploads files to a
>>>> server, and then sets the FileAttachment (subtype of ModelElement)
>>>> values. The upload itself is executed within a Job (Eclipse Worker
>>>> Thread), which means that the values are set from the Eclipse and not
>>>> from the UI-thread.
>>>>
>>>> public abstract class FileTransferJob extends Job ...
>>>>
>>>> protected void setAttributes() {
>>>> TransactionalEditingDomain domain =
>>>> TransactionalEditingDomain.Registry.INSTANCE
>>>> .getEditingDomain("...");
>>>> domain.getCommandStack().execute(new RecordingCommand(domain) {
>>>> @Override
>>>> protected void doExecute() {
>>>> if (fileAttachment.getFileID() == null ||
>>>> fileAttachment.getFileID().equals("")
>>>> || Integer.parseInt(fileAttachment.getFileID()) <=
>>>> fileInformation.getFileVersion()) {
>>>>
>>>> fileAttachment.setFileName(fileInformation.getFileName());
>>>> fileAttachment.setFileID("" +
>>>> fileInformation.getFileVersion());
>>>>
>>>> fileAttachment.setFileSize(fileInformation.getFileSize());
>>>> }
>>>> }
>>>> });
>>>> }
>>>>
>>>> As I cannot access any Display class to perform Display.syncExec() for
>>>> the very method that sets the values, (which would have solved the
>>>> problem), I started looking for other solutions.
>>>>
>>>> Would it be a good idea to subclass the
>>>> EditingDomainEObjectObservableValue and override the doSetValue() method
>>>> to make use of the Display.syncExec()-method?
>>>>
>>>> @Override
>>>> protected void doSetValue(Object value)
>>>> {
>>>> Command command = SetCommand.create(domain, eObject,
>>>> eStructuralFeature, value);
>>>> domain.getCommandStack().execute(command);
>>>> }
>>>>
>>>> I do hope someone finds the time to answer this question, I have so far
>>>> failed miserably ;)
>>>>
>>>> Cheers,
>>>> Carl
|
|
|
| Re: Setting ModelElement values from a non-UI thread [message #430985 is a reply to message #430984] |
Tue, 23 June 2009 07:17 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
No problem. If you need a jump start to EMF and Databinding you could
take a look at my blog series about EMF-Databinding in Galileo [1].
Though it is completely focused on EMF-Databinding.
Tom
[1] http://tomsondev.bestsolution.at/2009/06/06/galileo-improved -emf-databinding-support/
Carl Pfeiffer schrieb:
> Hi Tom,
>
> Right you are. Thanks for your help! I hope I wasn't bothering with too
> "easy" stuff, EMF is very new to me.
>
> Cheers,
> Carl
>
> Tom Schindl wrote:
>> Hi Carl,
>>
>> Obviously it is not the Databinding at least I didn't spot a single
>> method in the stack you are presenting.
>>
>> The stack you are presenting points to EMF-Edit stuff which is not
>> syncing calls from None-UI-Threads. IMHO the fix has to be in
>> "MELinkControl.java:70" where you need to check if you are on the
>> display thread before setting the text.
>>
>> Tom
>>
>> Carl Pfeiffer schrieb:
>>> Hi Tom,
>>>
>>> The Observable is located in a plugin without restrictions to the
>>> Display-class. The FileTransferJob classes are not, which would be the
>>> reason why I can only use Display in the Observable.
>>>
>>> As to the DataBinding, that is what I did and that is where it fails.
>>>
>>> IObservableValue model =
>>> EMFEditObservables.observeValue(getEditingDomain(), getModelElement(),
>>> attribute);
>>> EMFDataBindingContext dbc = new EMFDataBindingContext();
>>> dbc.bindValue(SWTObservables.observeText(fileName,
>>> SWT.FocusOut), model, null, null);
>>>
>>> That is where I bind the fileName value to the ModelElement.
>>>
>>> The StackTrace:
>>>
>>> org.eclipse.swt.SWTException: Invalid thread access
>>> at org.eclipse.swt.SWT.error(SWT.java:3884)
>>> at org.eclipse.swt.SWT.error(SWT.java:3799)
>>> at org.eclipse.swt.SWT.error(SWT.java:3770)
>>> at org.eclipse.swt.widgets.Widget.error(Widget.java:463)
>>> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:355)
>>> at org.eclipse.swt.widgets.Control.redraw(Control.java:2140)
>>> at org.eclipse.ui.forms.widgets.Hyperlink.setText(Hyperlink.jav a:183)
>>> at
>>> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkContr ol$1.labelProviderChanged(MELinkControl.java:70)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider .fireLabelProviderChanged(AdapterFactoryLabelProvider.java:6 73)
>>>
>>>
>>> at
>>> org.unicase.ui.meeditor.mecontrols.melinkcontrol.MELinkLabel Provider.notifyChanged(MELinkLabelProvider.java:36)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChang ed(ChangeNotifier.java:51)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNot ifyChanged(ComposedAdapterFactory.java:475)
>>>
>>>
>>> at
>>> org.unicase.model.attachment.provider.AttachmentItemProvider AdapterFactory.fireNotifyChanged(AttachmentItemProviderAdapt erFactory.java:204)
>>>
>>>
>>> at
>>> org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotify Changed(ItemProviderAdapter.java:220)
>>>
>>>
>>> at
>>> org.unicase.model.attachment.provider.FileAttachmentItemProv ider.notifyChanged(FileAttachmentItemProvider.java:155)
>>>
>>>
>>> at
>>> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify (BasicNotifierImpl.java:280)
>>>
>>>
>>> at
>>> org.unicase.model.attachment.impl.FileAttachmentImpl.setFile Name(FileAttachmentImpl.java:189)
>>>
>>>
>>> at
>>> org.unicase.model.attachment.impl.FileAttachmentImpl.eUnset( FileAttachmentImpl.java:366)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eUnset(BasicEObj ectImpl.java:1156)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:516)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(Fe atureChangeImpl.java:484)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.appl y(ChangeDescriptionImpl.java:297)
>>>
>
>>>
>>> at
>>> org.eclipse.emf.transaction.util.CompositeChangeDescription. apply(CompositeChangeDescription.java:104)
>>>
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionImpl.doRollback( TransactionImpl.java:570)
>>>
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:404)
>>>
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.TransactionalCommandStackIm pl.doExecute(TransactionalCommandStackImpl.java:70)
>>>
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:165)
>>>
>>>
>>> at
>>> org.eclipse.emf.transaction.impl.AbstractTransactionalComman dStack.execute(AbstractTransactionalCommandStack.java:219)
>>>
>>>
>>> at
>>> org.unicase.workspace.filetransfer.FileTransferJob.setAttrib utes(FileTransferJob.java:131)
>>>
>>>
>>> at
>>> org.unicase.workspace.filetransfer.FileUploadJob.run(FileUpl oadJob.java:62)
>>>
>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>>>
>>>
>>> Cheers,
>>> Carl
>>>
>>> Tom Schindl wrote:
>>>> Hi Carl,
>>>>
>>>> And where from would you get the display in the observable? Anyways
>>>> Eclipse-Databinding should have solved the problem for you (syncing
>>>> between different threads is done by the Realms).
>>>>
>>>> Can you give us a stacktrace?
>>>>
>>>> The easiest solution BTW is to use Display.geDefault() which gives you
>>>> access to the display from everywhere but as menntionned it should not
>>>> be a problem when using Eclipse-Databinding.
>>>>
>>>> Tom
>>>>
>>>> Carl Pfeiffer schrieb:
>>>>> Hi,
>>>>>
>>>>> I encountered some difficulties trying to set a ModelElement value
>>>>> from
>>>>> a non-UI thread, resulting in "Invalid Thread Access" exceptions.
>>>>>
>>>>> Now, the circumstances are as follows:
>>>>>
>>>>> There exists a client and a server. The client uploads files to a
>>>>> server, and then sets the FileAttachment (subtype of ModelElement)
>>>>> values. The upload itself is executed within a Job (Eclipse Worker
>>>>> Thread), which means that the values are set from the Eclipse and not
>>>>> from the UI-thread.
>>>>>
>>>>> public abstract class FileTransferJob extends Job ...
>>>>>
>>>>> protected void setAttributes() {
>>>>> TransactionalEditingDomain domain =
>>>>> TransactionalEditingDomain.Registry.INSTANCE
>>>>> .getEditingDomain("...");
>>>>> domain.getCommandStack().execute(new
>>>>> RecordingCommand(domain) {
>>>>> @Override
>>>>> protected void doExecute() {
>>>>> if (fileAttachment.getFileID() == null ||
>>>>> fileAttachment.getFileID().equals("")
>>>>> || Integer.parseInt(fileAttachment.getFileID()) <=
>>>>> fileInformation.getFileVersion()) {
>>>>>
>>>>> fileAttachment.setFileName(fileInformation.getFileName());
>>>>> fileAttachment.setFileID("" +
>>>>> fileInformation.getFileVersion());
>>>>>
>>>>> fileAttachment.setFileSize(fileInformation.getFileSize());
>>>>> }
>>>>> }
>>>>> });
>>>>> }
>>>>>
>>>>> As I cannot access any Display class to perform Display.syncExec() for
>>>>> the very method that sets the values, (which would have solved the
>>>>> problem), I started looking for other solutions.
>>>>>
>>>>> Would it be a good idea to subclass the
>>>>> EditingDomainEObjectObservableValue and override the doSetValue()
>>>>> method
>>>>> to make use of the Display.syncExec()-method?
>>>>>
>>>>> @Override
>>>>> protected void doSetValue(Object value)
>>>>> {
>>>>> Command command = SetCommand.create(domain, eObject,
>>>>> eStructuralFeature, value);
>>>>> domain.getCommandStack().execute(command);
>>>>> }
>>>>>
>>>>> I do hope someone finds the time to answer this question, I have so
>>>>> far
>>>>> failed miserably ;)
>>>>>
>>>>> Cheers,
>>>>> Carl
|
|
|
Goto Forum:
Current Time: Tue May 14 00:54:48 GMT 2024
Powered by FUDForum. Page generated in 0.04592 seconds |
] 
Search
Help
Register
Login
Home
