Home » Modeling » EMF » NPE during Batch Validation
| | |
| Re: NPE during Batch Validation [message #414277 is a reply to message #414275] |
Mon, 29 October 2007 13:18   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed, Lars,
An IModelConstraint is required to provide a descriptor -- it must never be
null.
If this problem happens only occasionally, then perhaps some synchronization
is required on the initialization of constraints in this application? In
general, the EMF Validation Framework is not thread-safe (as with the rest
of EMF) so the onus is on clients to provide concurrency controls.
Cheers,
Christian
Ed Merks wrote:
> Lars,
>
> I guess it's dying here because the descriptor is null:
>
> public boolean accept(Object constraint) {
> IConstraintDescriptor desc =
> ((IModelConstraint)constraint).getDescriptor();
>
> return (desc.isEnabled() && !isIgnored(desc));
> }
>
> It doesn't seem right that the descriptor should ever be null. Maybe
> Christian will have some theory as to why it might be null...
>
>
-----8<-----
|
|
|
| Re: NPE during Batch Validation [message #414278 is a reply to message #414276] |
Mon, 29 October 2007 13:29 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Lars,
I don't think there's anything that your application could do to cause this
concurrent modification except actually running validation on multiple
concurrent threads, which isn't supported. Is that what you're doing?
Perhaps we could investigate the possibility of protecting the
initialization of constraints in the stock XML-based provider from
concurrent access. Care to raise an enhancement request? Attaching a
reproducible use case to it would help a lot. Even more helpful, of
course, would be a patch :-)
Cheers,
Christian
Lars Heinemann wrote:
> I just found another stacktrace in the Error-Log, only milliseconds
> before the NPE:
>
> java.util.ConcurrentModificationException
> at
> java.util.AbstractList$Itr.checkForComodification(AbstractLi st.java:449)
> at java.util.AbstractList$Itr.next(AbstractList.java:420) at
>
org.eclipse.emf.validation.xml.XmlConstraintProvider.getBatc hConstraints(XmlConstraintProvider.java:272)
> at
>
org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 6)
> at
>
org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :129)
> at
>
org.eclipse.emf.validation.internal.service.ConstraintCache. execute(ConstraintCache.java:284)
> at
>
org.eclipse.emf.validation.internal.service.ConstraintCache. getBatchConstraints(ConstraintCache.java:384)
> at
>
org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 6)
> at
>
org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :129)
> at
>
org.eclipse.emf.validation.service.ModelValidationService.ex ecute(ModelValidationService.java:356)
> at
>
org.eclipse.emf.validation.service.ModelValidationService.ac cess$2(ModelValidationService.java:350)
> at
>
org.eclipse.emf.validation.service.ModelValidationService$1. execute(ModelValidationService.java:121)
> at
>
org.eclipse.emf.validation.internal.service.AbstractValidato r.execute(AbstractValidator.java:268)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:236)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:192)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.d oValidate(BatchValidator.java:137)
> at
>
org.eclipse.emf.validation.internal.service.AbstractValidato r.validate(AbstractValidator.java:136)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:121)
>
-----8<-----
|
|
|
| Re: NPE during Batch Validation [message #414279 is a reply to message #414278] |
Mon, 29 October 2007 13:51 |
 Lars Heinemann
Messages: 37
Registered: July 2009 |
Member |
|
|
Hi Christian,
yes we do call the BatchValidator from two different threads.
First it is called from within a builder, which runs quite a while for
large models and the second one is from a command stack listener to
provide some instant validation while editing.
At present I can't think of anything else but wrapping the call to
IBatchValidator.validate with a lock to prevent the problem. But this
would mean that the command stack could have to wait for the builder,
which would be unacceptable.
I will open an enhancement request, however I have to find a solution
based on the release that 'fits' Eclipse 3.2/EMF 2.2.
Cheers,
Lars
Christian W. Damus schrieb:
> Hi, Lars,
>
> I don't think there's anything that your application could do to cause this
> concurrent modification except actually running validation on multiple
> concurrent threads, which isn't supported. Is that what you're doing?
> Perhaps we could investigate the possibility of protecting the
> initialization of constraints in the stock XML-based provider from
> concurrent access. Care to raise an enhancement request? Attaching a
> reproducible use case to it would help a lot. Even more helpful, of
> course, would be a patch :-)
>
> Cheers,
>
> Christian
>
>
> Lars Heinemann wrote:
>
>> I just found another stacktrace in the Error-Log, only milliseconds
>> before the NPE:
>>
>> java.util.ConcurrentModificationException
>> at
>> java.util.AbstractList$Itr.checkForComodification(AbstractLi st.java:449)
>> at java.util.AbstractList$Itr.next(AbstractList.java:420) at
>>
> org.eclipse.emf.validation.xml.XmlConstraintProvider.getBatc hConstraints(XmlConstraintProvider.java:272)
>> at
>>
> org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 6)
>> at
>>
> org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :129)
>> at
>>
> org.eclipse.emf.validation.internal.service.ConstraintCache. execute(ConstraintCache.java:284)
>> at
>>
> org.eclipse.emf.validation.internal.service.ConstraintCache. getBatchConstraints(ConstraintCache.java:384)
>> at
>>
> org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 6)
>> at
>>
> org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :129)
>> at
>>
> org.eclipse.emf.validation.service.ModelValidationService.ex ecute(ModelValidationService.java:356)
>> at
>>
> org.eclipse.emf.validation.service.ModelValidationService.ac cess$2(ModelValidationService.java:350)
>> at
>>
> org.eclipse.emf.validation.service.ModelValidationService$1. execute(ModelValidationService.java:121)
>> at
>>
> org.eclipse.emf.validation.internal.service.AbstractValidato r.execute(AbstractValidator.java:268)
>> at
>>
> org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:236)
>> at
>>
> org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:192)
>> at
>>
> org.eclipse.emf.validation.internal.service.BatchValidator.d oValidate(BatchValidator.java:137)
>> at
>>
> org.eclipse.emf.validation.internal.service.AbstractValidato r.validate(AbstractValidator.java:136)
>> at
>>
> org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:121)
>
> -----8<-----
|
|
|
| Re: NPE during Batch Validation [message #414281 is a reply to message #414279] |
Mon, 29 October 2007 15:49 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Lars,
For version 1.0 of the validation component (which is what you need for
Eclipse 3.2), you may be able to work around this problem if you don't mind
using internal API.
The XmlConstraintProvider that you see in your stack traces is simply the
default constraint provider when none is specified in the
<constraintProvider> element in the plugin.xml. You can identify a custom
provider using the "class" attribute. To continue using the plugin.xml
method of declaring constraints, you could specify a subclass (defined by
you) of the XmlConstraintProvider and implement the synchronization, there.
HTH,
Christian
Lars Heinemann wrote:
> Hi Christian,
>
> yes we do call the BatchValidator from two different threads.
> First it is called from within a builder, which runs quite a while for
> large models and the second one is from a command stack listener to
> provide some instant validation while editing.
> At present I can't think of anything else but wrapping the call to
> IBatchValidator.validate with a lock to prevent the problem. But this
> would mean that the command stack could have to wait for the builder,
> which would be unacceptable.
> I will open an enhancement request, however I have to find a solution
> based on the release that 'fits' Eclipse 3.2/EMF 2.2.
>
> Cheers,
> Lars
-----8<-----
|
|
|
| Re: NPE during Batch Validation [message #415961 is a reply to message #414281] |
Mon, 14 January 2008 10:02 |
Lars Heinemann
Messages: 37
Registered: July 2009 |
Member |
|
|
Christian,
thanks for the hint. Can you think of a solution without using EMF
internal code?
Cheers,
Lars
Christian W. Damus schrieb:
> Hi, Lars,
>
> For version 1.0 of the validation component (which is what you need for
> Eclipse 3.2), you may be able to work around this problem if you don't mind
> using internal API.
>
> The XmlConstraintProvider that you see in your stack traces is simply the
> default constraint provider when none is specified in the
> <constraintProvider> element in the plugin.xml. You can identify a custom
> provider using the "class" attribute. To continue using the plugin.xml
> method of declaring constraints, you could specify a subclass (defined by
> you) of the XmlConstraintProvider and implement the synchronization, there.
>
> HTH,
>
> Christian
>
>
> Lars Heinemann wrote:
>
>> Hi Christian,
>>
>> yes we do call the BatchValidator from two different threads.
>> First it is called from within a builder, which runs quite a while for
>> large models and the second one is from a command stack listener to
>> provide some instant validation while editing.
>> At present I can't think of anything else but wrapping the call to
>> IBatchValidator.validate with a lock to prevent the problem. But this
>> would mean that the command stack could have to wait for the builder,
>> which would be unacceptable.
>> I will open an enhancement request, however I have to find a solution
>> based on the release that 'fits' Eclipse 3.2/EMF 2.2.
>>
>> Cheers,
>> Lars
>
> -----8<-----
|
|
|
| Re: NPE during Batch Validation [message #415965 is a reply to message #415961] |
Mon, 14 January 2008 15:38 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Lars,
The only other approach that I could suggest would be to define your own
constraint provider "from scratch" (implementing IModelConstraintProvider)
that doesn't declare the constraints in the plugin.xml. This gives you the
flexibility to define constraints in a more convenient format, perhaps even
as EMF resources modeled using Ecore, and would relieve the extension
registry of a non-trivial load of data.
Of course, this is a much more heavy-weight solution, but might provide
additional benefits that make it worth your while in the long run.
Cheers,
Christian
Lars Heinemann wrote:
> Christian,
>
> thanks for the hint. Can you think of a solution without using EMF
> internal code?
>
> Cheers,
> Lars
>
> Christian W. Damus schrieb:
>> Hi, Lars,
>>
>> For version 1.0 of the validation component (which is what you need for
>> Eclipse 3.2), you may be able to work around this problem if you don't
>> mind using internal API.
>>
>> The XmlConstraintProvider that you see in your stack traces is simply the
>> default constraint provider when none is specified in the
>> <constraintProvider> element in the plugin.xml. You can identify a
>> custom
>> provider using the "class" attribute. To continue using the plugin.xml
>> method of declaring constraints, you could specify a subclass (defined by
>> you) of the XmlConstraintProvider and implement the synchronization,
>> there.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Lars Heinemann wrote:
>>
>>> Hi Christian,
>>>
>>> yes we do call the BatchValidator from two different threads.
>>> First it is called from within a builder, which runs quite a while for
>>> large models and the second one is from a command stack listener to
>>> provide some instant validation while editing.
>>> At present I can't think of anything else but wrapping the call to
>>> IBatchValidator.validate with a lock to prevent the problem. But this
>>> would mean that the command stack could have to wait for the builder,
>>> which would be unacceptable.
>>> I will open an enhancement request, however I have to find a solution
>>> based on the release that 'fits' Eclipse 3.2/EMF 2.2.
>>>
>>> Cheers,
>>> Lars
>>
>> -----8<-----
|
|
|
Goto Forum:
Current Time: Thu Apr 25 14:02:09 GMT 2024
Powered by FUDForum. Page generated in 0.04187 seconds |
] 
Search
Help
Register
Login
Home
