Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 292731 - INVALID object throws Exception from eResource() call -- but should return null
Summary: INVALID object throws Exception from eResource() call -- but should return null
Status: CLOSED FIXED
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eike Stepper CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-20 02:11 EDT by Caspar D. CLA
Modified: 2010-06-29 09:22 EDT (History)
1 user (show)

See Also:
stepper: review+

Attachments
Patch for 2.0.0 (956 bytes, patch)
2009-10-20 02:28 EDT, Caspar D. CLA 		no flags Details | Diff
Patch for 2.0.1 (900 bytes, patch)
2009-11-06 00:16 EST, Caspar D. CLA 		stepper: iplog+
Details | Diff
Show Obsolete (1) 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 Caspar D. CLA 2009-10-20 02:11:40 EDT 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14) Gecko/2009090216 Firefox/3.0.1
Build Identifier: CDO 2.0.0.v200906160459

It seems reasonable for an app to assume that it can safely check
whether an object is still connected to the graph by checking
eResource() != null.

And indeed this works fine for objects that were disconnected locally
(and hence are TRANSIENT). But when eResource() is called on a
CDOObjectImpl in state INVALID (i.e. detached remotely), an
InvalidObjectException is thrown.

I think it doesn't quite make sense for eResource() to behave
differently for objects that were detached remotely than for objects
that were detached locally. The caller just wants to know if the object
is still connected or not, and so is probably best served by receiving
null in the case of an INVALID object, same as for a TRANSIENT object.

Note that it's not just application code that assumes eResource() is
safe to call. The "higher-level" parts of EMF, such as validation,
assume this too. For these EMF tools to work with CDOObjects (which,
AFAIAC is highly desirable ;-)) would require eResource to return null for INVALID objects.

Reproducible: Always
Comment 1 Caspar D. CLA 2009-10-20 02:28:48 EDT 
Created attachment 149951 [details]
Patch for 2.0.0

This patch adds an override for BasicEObjectImpl.eInternalResource to preempt the base implementation's handling of INVALID CDOobjects.

Amending CDOObjectImpl.eDirectResource was insufficient because then eInternalResource starts a walk up the container hierarchy, which causes a read op on the INVALID object, which also gives an exception.
Comment 2 Eike Stepper CLA 2009-11-05 07:56:53 EST 
It seems as if this patch got out of sync ;-(
Can you please re-integrate it?
Comment 3 Caspar D. CLA 2009-11-06 00:16:14 EST 
Created attachment 151525 [details]
Patch for 2.0.1

As requested, uploading a patch generated relative to the current (Nov-6) codebase in R2_0_maintenance.
Comment 4 Eike Stepper CLA 2009-11-06 01:54:57 EST 
Committed to R2_0_maintenance
Comment 5 Eike Stepper CLA 2009-11-06 01:56:00 EST 
Comment on attachment 151525 [details]
Patch for 2.0.1

Please confirm that:

1) The number of lines that you changed is smaller than 250.
2) You are the only author of these changed lines.
3) You apply the EPL to these changed lines.
Comment 6 Caspar D. CLA 2009-11-06 03:16:32 EST 
(In reply to comment #5)
> (From update of attachment 151525 [details])
> Please confirm that:
> 
> 1) The number of lines that you changed is smaller than 250.
> 2) You are the only author of these changed lines.
> 3) You apply the EPL to these changed lines.

I confirm.