Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 361250 - Resource cannot be removed from resource set
Summary: Resource cannot be removed from resource set
Status: CLOSED WORKSFORME
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 4.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Victor Roldan Betancort CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on: 338921
Blocks:
  Show dependency tree
 
Reported: 2011-10-18 07:48 EDT by Egidijus Vaisnora CLA
Modified: 2011-12-15 11:09 EST (History)
1 user (show)

See Also:

Attachments
Test case (1.90 KB, patch)
2011-10-18 07:55 EDT, Egidijus Vaisnora CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Egidijus Vaisnora CLA 2011-10-18 07:48:42 EDT 
Create Resource from CDO transaction, get ResourceSet and remove Resource. This operation fails with following exception:

Caused by: org.eclipse.emf.cdo.common.util.CDOException: Attempt to remove a dirty resource from a resource set: CDOResource@oid2
	at org.eclipse.emf.internal.cdo.view.CDOViewSetImpl.deregisterResources(CDOViewSetImpl.java:302)
	at org.eclipse.emf.internal.cdo.view.CDOViewSetImpl.notifyChanged(CDOViewSetImpl.java:259)
	at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:380)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.dispatchNotification(NotifyingListImpl.java:267)
	at org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(NotifyingListImpl.java:719)
	at org.eclipse.emf.common.util.AbstractEList.remove(AbstractEList.java:466)
	at org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_360767_Test.testResourceRemoteDetachRemovalNotification(Bugzilla_360767_Test.java:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at org.eclipse.net4j.util.tests.AbstractOMTest.runBare(AbstractOMTest.java:221)
	at org.eclipse.emf.cdo.tests.config.impl.ConfigTest.runBare(ConfigTest.java:526)
	... 33 more
Comment 1 Egidijus Vaisnora CLA 2011-10-18 07:55:11 EDT 
Created attachment 205416 [details]
Test case
Comment 2 Eike Stepper CLA 2011-10-18 12:19:53 EDT 
Are you going to provide a test case?
Comment 3 Eike Stepper CLA 2011-10-18 12:20:10 EDT 
Argh, ignore my silly question!
Comment 4 Eike Stepper CLA 2011-10-18 12:24:47 EDT 
This bug has been introduced with the fix to bug 338921. Assigning to Vik for analysis.
Comment 5 Victor Roldan Betancort CLA 2011-12-15 10:28:06 EST 
I believe that exception is expected. Not exactly sure about the reasons why we introduced it, but its probably related with the fact that if you remove a dirty CDOResource (in this case, a it's in state NEW), the underlying CDOTransaction is left dirty, and that may introduce unwanted changes to future commits. Performing rollback automatically is probably not safe, so I guess this exception is indicating "please tidy up your changes before discarding that resource". Eike, do you recall anything about this?

Furthermore, even if that exception didn't raise, yet another would raise, because the resource doesn't exist (the resource is not committed, and neither its part of the ResourceSet, as it has been removed).
So the last 3 lines of code of the test-case would fail anyway. What were you exactly trying to achieve?
Comment 6 Eike Stepper CLA 2011-12-15 11:09:44 EST 
I remember now and agree with Vik, this is the expected behaviour.