Home » Modeling » OCL » java.util.ConcurrentModificationException
|
| Re: java.util.ConcurrentModificationException [message #63346 is a reply to message #63322] |
Mon, 27 October 2008 15:25   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Mark,
This sounds like an EMF Validation Framework question, so I am including
that newsgroup in my reply.
If you are only changing the definition of the OCL constraint, then you
shouldn't need to remove its descriptor, but just its IModelConstraint
implementation. How to do that depends on how you have implemented the
constraint.
The out-of-the-box OCL support provided by the
org.eclipse.emf.validation.ocl feature assumes that OCL constraints are
statically defined and won't change, because they are part of or
extensions to the target model. If you're currently using that, then
your best bet may be to desist and implement your own OCL constraint
provider. This could be a dynamic constraint provider, after the
fashion of the org.eclipse.emf.validation.examples.ocl example, or by
defining your own "constraint language" on the
org.eclipse.emf.validation.parsers extension point. Either way, you
will have control over the constraint implementation, so that you can
make its guts more flexible without confusing the outside world by
messing with constraint descriptors.
In any case, it should be possible to manipulate the constraint
descriptors and categories in the way that you need. Can you provide a
stack trace, and maybe a code snippet? I haven't seen this particular
problem, before.
Cheers,
Christian
Mark Melia wrote:
> Hi All,
>
> I am trying to allow for OCL constraints to be changed at runtime in my
> application. I think that the constraints are getting stored (cached) in
> the category so if a constraint is changed it keeps the old one.
> Everytime I try and remove the constraints from the category I get the
> java.util.ConcurrentModificationException exception. I am trying to
> remove the constraints in the BatchValidationDelegate class, if that helps.
>
> Does anyone know whats going on?
>
> Thanks,
> Mark
>
|
|
|
| Re: java.util.ConcurrentModificationException [message #63436 is a reply to message #63346] |
Tue, 28 October 2008 16:05 |
 Mark Melia
Messages: 142
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks for your reply.
> If you are only changing the definition of the OCL constraint, then you
> shouldn't need to remove its descriptor, but just its IModelConstraint
> implementation. How to do that depends on how you have implemented the
> constraint.
I may want to add new OCL constraints and delete existing ones - I think
then there is a case for removing the descriptor.
We are using and extending the org.eclipse.emf.validation.examples.ocl
example. Keeping this in mind to remove constraints I have extended the
parseConstraints method in the OCLConstraintProvider.
I should note that the exception does not always happen, after 2 or 3
validation the exception (after code snippet) is thrown.
Thanks,
Mark
private void parseConstraints(Category category, String namespace,
InputStream input) throws ParserException {
OCLInput oclInput = new OCLInput(input);
OCL ocl = OCL.newInstance();
ArrayList <String> thisConstraints = new ArrayList<String>();
for (Constraint constraint : ocl.parse(oclInput)) {
if (isInvariant(constraint)) {
// only add invariant constraints for validation
thisConstraints.add(constraint.getName());
addConstraint(category, namespace, ocl, constraint);
}
}
java.util.Iterator <IModelConstraint> itr = constraints.iterator();
while(itr.hasNext()){
IModelConstraint c = (IModelConstraint)itr.next();
if(!thisConstraints.contains(c.getDescriptor().getName())){
System.out.println("getting rid of "+c.getDescriptor().getName());
constraints.remove(c);
}
}
}
Stack trace:
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.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:149)
at
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:113)
at
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.getConstraints(OCLConstraintProvider.java:87)
at
org.eclipse.emf.validation.service.AbstractConstraintProvide r.getBatchConstraints(AbstractConstraintProvider.java:328)
at
org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 7)
at
org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :132)
at
org.eclipse.emf.validation.service.ModelValidationService.ex ecute(ModelValidationService.java:398)
at
org.eclipse.emf.validation.service.ModelValidationService.ac cess$2(ModelValidationService.java:392)
at
org.eclipse.emf.validation.service.ModelValidationService$1. execute(ModelValidationService.java:206)
at
org.eclipse.emf.validation.internal.service.AbstractValidato r.execute(AbstractValidator.java:287)
at
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:238)
at
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:194)
at
org.eclipse.emf.validation.internal.service.BatchValidator.d oValidate(BatchValidator.java:139)
at
org.eclipse.emf.validation.internal.service.AbstractValidato r.validate(AbstractValidator.java:140)
at
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.run(BatchValidationDelegate.java:210)
at
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.runWithEvent(BatchValidationDelegate.java:16 3)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:241)
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:583)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:500)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1561)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1585)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1570)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1 360)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3474)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3064)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
> The out-of-the-box OCL support provided by the
> org.eclipse.emf.validation.ocl feature assumes that OCL constraints are
> statically defined and won't change, because they are part of or
> extensions to the target model. If you're currently using that, then
> your best bet may be to desist and implement your own OCL constraint
> provider. This could be a dynamic constraint provider, after the
> fashion of the org.eclipse.emf.validation.examples.ocl example, or by
> defining your own "constraint language" on the
> org.eclipse.emf.validation.parsers extension point. Either way, you
> will have control over the constraint implementation, so that you can
> make its guts more flexible without confusing the outside world by
> messing with constraint descriptors.
> In any case, it should be possible to manipulate the constraint
> descriptors and categories in the way that you need. Can you provide a
> stack trace, and maybe a code snippet? I haven't seen this particular
> problem, before.
> Cheers,
> Christian
> Mark Melia wrote:
>> Hi All,
>>
>> I am trying to allow for OCL constraints to be changed at runtime in my
>> application. I think that the constraints are getting stored (cached) in
>> the category so if a constraint is changed it keeps the old one.
>> Everytime I try and remove the constraints from the category I get the
>> java.util.ConcurrentModificationException exception. I am trying to
>> remove the constraints in the BatchValidationDelegate class, if that helps.
>>
>> Does anyone know whats going on?
>>
>> Thanks,
>> Mark
>>
|
|
|
| Re: java.util.ConcurrentModificationException [message #63505 is a reply to message #63436] |
Tue, 28 October 2008 17:48 |
Mark Melia
Messages: 142
Registered: July 2009 |
Senior Member |
|
|
Hi all,
Sorry silly error - I was manipulating the arraylist while iterating it.
Mark
Mark Melia wrote:
> Hi Christian,
> Thanks for your reply.
>> If you are only changing the definition of the OCL constraint, then you
>> shouldn't need to remove its descriptor, but just its IModelConstraint
>> implementation. How to do that depends on how you have implemented the
>> constraint.
> I may want to add new OCL constraints and delete existing ones - I think
> then there is a case for removing the descriptor.
> We are using and extending the org.eclipse.emf.validation.examples.ocl
> example. Keeping this in mind to remove constraints I have extended the
> parseConstraints method in the OCLConstraintProvider.
> I should note that the exception does not always happen, after 2 or 3
> validation the exception (after code snippet) is thrown.
> Thanks,
> Mark
> private void parseConstraints(Category category, String namespace,
> InputStream input) throws ParserException {
> OCLInput oclInput = new OCLInput(input);
> OCL ocl = OCL.newInstance();
> ArrayList <String> thisConstraints = new ArrayList<String>();
> for (Constraint constraint : ocl.parse(oclInput)) {
> if (isInvariant(constraint)) {
> // only add invariant constraints for validation
> thisConstraints.add(constraint.getName());
> addConstraint(category, namespace, ocl, constraint);
> }
> }
> java.util.Iterator <IModelConstraint> itr = constraints.iterator();
> while(itr.hasNext()){
> IModelConstraint c = (IModelConstraint)itr.next();
> if(!thisConstraints.contains(c.getDescriptor().getName())){
> System.out.println("getting rid of "+c.getDescriptor().getName());
> constraints.remove(c);
> }
> }
> }
> Stack trace:
> 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.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:149)
> at
>
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.parseConstraints(OCLConstraintProvider.java:113)
> at
>
org.eclipse.emf.validation.examples.ocl.OCLConstraintProvide r.getConstraints(OCLConstraintProvider.java:87)
> at
>
org.eclipse.emf.validation.service.AbstractConstraintProvide r.getBatchConstraints(AbstractConstraintProvider.java:328)
> at
>
org.eclipse.emf.validation.internal.service.GetBatchConstrai ntsOperation.executeImpl(GetBatchConstraintsOperation.java:5 7)
> at
>
org.eclipse.emf.validation.internal.service.AbstractGetConst raintsOperation.execute(AbstractGetConstraintsOperation.java :132)
> at
>
org.eclipse.emf.validation.service.ModelValidationService.ex ecute(ModelValidationService.java:398)
> at
>
org.eclipse.emf.validation.service.ModelValidationService.ac cess$2(ModelValidationService.java:392)
> at
>
org.eclipse.emf.validation.service.ModelValidationService$1. execute(ModelValidationService.java:206)
> at
>
org.eclipse.emf.validation.internal.service.AbstractValidato r.execute(AbstractValidator.java:287)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:238)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.v alidate(BatchValidator.java:194)
> at
>
org.eclipse.emf.validation.internal.service.BatchValidator.d oValidate(BatchValidator.java:139)
> at
>
org.eclipse.emf.validation.internal.service.AbstractValidato r.validate(AbstractValidator.java:140)
> at
>
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.run(BatchValidationDelegate.java:210)
> at
>
org.eclipse.emf.validation.examples.general.actions.BatchVal idationDelegate.runWithEvent(BatchValidationDelegate.java:16 3)
> at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:241)
> at
>
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:583)
> at
>
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:500)
> at
>
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:411)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1561)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1585)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1570)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1 360)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3474)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3064)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2382)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 98)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:488)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
>
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:113)
> at
>
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
> at
>
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
> at
>
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:382)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
>> The out-of-the-box OCL support provided by the
>> org.eclipse.emf.validation.ocl feature assumes that OCL constraints are
>> statically defined and won't change, because they are part of or
>> extensions to the target model. If you're currently using that, then
>> your best bet may be to desist and implement your own OCL constraint
>> provider. This could be a dynamic constraint provider, after the
>> fashion of the org.eclipse.emf.validation.examples.ocl example, or by
>> defining your own "constraint language" on the
>> org.eclipse.emf.validation.parsers extension point. Either way, you
>> will have control over the constraint implementation, so that you can
>> make its guts more flexible without confusing the outside world by
>> messing with constraint descriptors.
>> In any case, it should be possible to manipulate the constraint
>> descriptors and categories in the way that you need. Can you provide a
>> stack trace, and maybe a code snippet? I haven't seen this particular
>> problem, before.
>> Cheers,
>> Christian
>> Mark Melia wrote:
>>> Hi All,
>>>
>>> I am trying to allow for OCL constraints to be changed at runtime in my
>>> application. I think that the constraints are getting stored (cached) in
>>> the category so if a constraint is changed it keeps the old one.
>>> Everytime I try and remove the constraints from the category I get the
>>> java.util.ConcurrentModificationException exception. I am trying to
>>> remove the constraints in the BatchValidationDelegate class, if that helps.
>>>
>>> Does anyone know whats going on?
>>>
>>> Thanks,
>>> Mark
>>>
|
|
|
| Re: java.util.ConcurrentModificationException [message #63528 is a reply to message #63505] |
Tue, 28 October 2008 17:54 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Mark,
Yes, I think you wanted iter.remove() instead of constraints.remove(c)
However, it is odd that this happens sporadically -- it looks like a
sure bomb.
You're sure that all is well, now?
cW
Mark Melia wrote:
> Hi all,
>
> Sorry silly error - I was manipulating the arraylist while iterating it.
>
> Mark
>
> Mark Melia wrote:
>
-----8<-----
|
|
|
| Re: java.util.ConcurrentModificationException [message #63731 is a reply to message #63528] |
Thu, 30 October 2008 12:42 |
Mark Melia
Messages: 142
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Yeah it was just a stupid coding mistake I made.
One more question for you. In the OCLConstraintProvider you wrote for the
example if you set up an instance list variable to hold all the
constraints and the getConstraints method returns it all the constraints
are registered correctly, however if you set up a local variable to do the
exact same thing it doesn't work.
Also with this instance variable - if you clear it at the start of the
getConstraints method, the constraints again wont be registered correctly.
Any idea what is happening here?
Mark
Christian W. Damus wrote:
> Hi, Mark,
> Yes, I think you wanted iter.remove() instead of constraints.remove(c)
> However, it is odd that this happens sporadically -- it looks like a
> sure bomb.
> You're sure that all is well, now?
> cW
> Mark Melia wrote:
>> Hi all,
>>
>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>
>> Mark
>>
>> Mark Melia wrote:
>>
> -----8<-----
|
|
| |
| Re: java.util.ConcurrentModificationException [message #63776 is a reply to message #63754] |
Thu, 30 October 2008 12:58 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Tom,
Yes, that must be it. Collections don't track their iterators, so the
check can't be done on the modify side.
Thanks!
Christian
Tom Schindl wrote:
> The reason for this happening sporadically is that if
> constraints.remove(c) is the last action (e.g. because you are already
> on the last element and hasNext() returns false, break the loop ...).
>
> The CME is only thrown on the next call to it.next() where the
> modification counter of the underlying Collection is checked.
>
> Tom
>
> Christian W. Damus schrieb:
>> Hi, Mark,
>>
>> Yes, I think you wanted iter.remove() instead of constraints.remove(c)
>>
>> However, it is odd that this happens sporadically -- it looks like a
>> sure bomb.
>>
>> You're sure that all is well, now?
>>
>> cW
>>
>> Mark Melia wrote:
>>> Hi all,
>>>
>>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>>
>>> Mark
>>>
>>> Mark Melia wrote:
>>>
>> -----8<-----
>
>
|
|
|
| Re: java.util.ConcurrentModificationException [message #63908 is a reply to message #63731] |
Thu, 30 October 2008 15:39 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Mark,
The example OCLConstraintProvider is designed to be dynamic inasmuch as
the constraints it provides are discovered at run-time, buth these
constraints in and of themselves are not changeable (they are just
loaded from text files).
So, you can see that it calls the registerConstraints() method inherited
from the AbstractConstraintProvider in the setInitializationData()
method. This is done exactly once. Moreover, the constraints that it
registers are those that are stared in the superclass's field, a list
that is appended by the addConstraint() method.
If you are maintaining a list of constraints locally in some method,
containing newly-created constraints, then you can use the same
registerConstraints() method to ensure that they are registered.
HTH,
Christian
Mark Melia wrote:
> Hi Christian,
>
> Yeah it was just a stupid coding mistake I made.
>
> One more question for you. In the OCLConstraintProvider you wrote for
> the example if you set up an instance list variable to hold all the
> constraints and the getConstraints method returns it all the constraints
> are registered correctly, however if you set up a local variable to do
> the exact same thing it doesn't work.
>
> Also with this instance variable - if you clear it at the start of the
> getConstraints method, the constraints again wont be registered correctly.
>
> Any idea what is happening here?
> Mark
>
>
> Christian W. Damus wrote:
>
>> Hi, Mark,
>
>> Yes, I think you wanted iter.remove() instead of constraints.remove(c)
>
>> However, it is odd that this happens sporadically -- it looks like a
>> sure bomb.
>
>> You're sure that all is well, now?
>
>> cW
>
>> Mark Melia wrote:
>>> Hi all,
>>>
>>> Sorry silly error - I was manipulating the arraylist while iterating it.
>>>
>>> Mark
>>>
>>> Mark Melia wrote:
>>>
>
>> -----8<-----
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 14:05:01 GMT 2024
Powered by FUDForum. Page generated in 0.03370 seconds |
] 
Search
Help
Register
Login
Home
