|
|
|
Re: Intermittent Validation Job failures on editor close [message #992320 is a reply to message #992305] |
Fri, 21 December 2012 10:49 |
Sebastian Zarnekow Messages: 3118 Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
there is exactly one job per document. The job is re-triggered so
canceling that one should work. I don't know about any code in Xtext
that would trigger a concurrent validation job besides an explicit
invocation of the ValidateActionHandler.
Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 21.12.12 11:12, schrieb Ed Willink:
> Hi Sebastian
>
> Sorry, I should have been clearer.
>
> I suspect that it's the concurrent ValidationJob rather than the
> scheduled ValidationJob that's the problem, so I need to be able to get
> at the IProgressMonitor to cancel that.
>
> Regards
>
> Ed Willink
>
>
> On 21/12/2012 09:53, Sebastian Zarnekow wrote:
>> Hi Ed,
>>
>> I'd expect
>>
>> XtextDocumentProvider.disposeElementInfo(Object, ElementInfo)
>>
>> to cancel the validation job.
>> You may always use XtextDocument.getValidationJob() to cancel a
>> pending job manually.
>>
>> Regards,
>> Sebastian
>>
>> Am 20.12.12 15:49, schrieb Ed Willink:
>>> Hi
>>>
>>> I have some JUnit plugin tests that open an Xtext editor and do trivial
>>> sets/replaces on the document to emulate user editing before closing.
>>>
>>> I occasionally get a
>>>
>>> java.lang.Error: Invalid replace region [0 / length: 221]
>>> originalLength=218
>>> at
>>> org.eclipse.ocl.examples.pivot.tests.PivotTestSuite$TestCaseAppender.append(PivotTestSuite.java:157)
>>>
>>>
>>> at
>>> org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
>>> at
>>> org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
>>>
>>>
>>> at org.apache.log4j.Category.callAppenders(Category.java:206)
>>> at org.apache.log4j.Category.forcedLog(Category.java:391)
>>> at org.apache.log4j.Category.error(Category.java:305)
>>> at
>>> org.eclipse.xtext.parser.impl.PartialParsingHelper.reparse(PartialParsingHelper.java:80)
>>>
>>>
>>> at
>>> org.eclipse.xtext.parser.antlr.AbstractAntlrParser.doReparse(AbstractAntlrParser.java:136)
>>>
>>>
>>> at
>>> org.eclipse.xtext.parser.AbstractParser.reparse(AbstractParser.java:48)
>>> at
>>> org.eclipse.xtext.resource.XtextResource.update(XtextResource.java:217)
>>> at
>>> org.eclipse.xtext.ui.editor.reconciler.XtextReconcilerUnitOfWork.process(XtextReconcilerUnitOfWork.java:55)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.reconciler.XtextReconcilerUnitOfWork.process(XtextReconcilerUnitOfWork.java:1)
>>>
>>>
>>> at
>>> org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36)
>>>
>>>
>>> at
>>> org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.modify(AbstractReadWriteAcces.java:51)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:188)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.process(XtextDocument.java:209)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$DocumentListener.performNecessaryUpdates(XtextReconciler.java:81)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.model.XtextDocument.updateContentBeforeRead(XtextDocument.java:142)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.beforeReadOnly(XtextDocument.java:162)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.beforeReadOnly(XtextDocument.java:1)
>>>
>>>
>>> at
>>> org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces.readOnly(AbstractReadWriteAcces.java:31)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:78)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(ValidationJob.java:75)
>>>
>>>
>>> at
>>> org.eclipse.xtext.ui.editor.validation.ValidationJob.run(ValidationJob.java:64)
>>>
>>>
>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
>>>
>>> from a residual ValidationJob.
>>>
>>> It does not appear to be easy to customize the ValidationJob class or
>>> get at the existing one to cancel it.
>>>
>>> Is there a reliable way to ensure that ValidationJobs are killed off
>>> when closing an editor?
>>>
>>> Regards
>>>
>>> Ed Willink
>>
>>
>
|
|
|
|
Re: Intermittent Validation Job failures on editor close [message #992538 is a reply to message #992346] |
Fri, 21 December 2012 22:38 |
Sebastian Zarnekow Messages: 3118 Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I suggest to override #newValidationJob and use the one from the document.
You may want to follow: https://bugs.eclipse.org/bugs/show_bug.cgi?id=397109
According to JobManager.cancel(InternalJob) this will allow to cancel
the initial job, too.
Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 21.12.12 12:57, schrieb Ed Willink:
> Hi
>
> There are actually two: a one-off created on opening with
> newValidatorJob, and the rescheduled one create by new ValidatorJob.
>
> I observe that in the main thread my JUnit test does a document edit,
> flushes events, checks the document, and closes.
>
> Concurrently the (one) ValidationJob runs in the worker thread and may
> presumably start running before and finish running after the editor
> close. Cancelling the job only kills the next run. I need to terminate
> this run.
>
> Regards
>
> Ed Willink
>
> On 21/12/2012 10:49, Sebastian Zarnekow wrote:
>> Hi Ed,
>>
>> there is exactly one job per document. The job is re-triggered so
>> canceling that one should work. I don't know about any code in Xtext
>> that would trigger a concurrent validation job besides an explicit
>> invocation of the ValidateActionHandler.
>>
>> Regards,
>> Sebastian
>
|
|
|
Powered by
FUDForum. Page generated in 0.03755 seconds