Community
Participate
Working Groups
I think it would make sense if the method DefaultResourceDescriptionStrategy#isResolvedAndExternal(EObject, EObject) would also check if the target object is an non contained object. I.e. in case it is not a proxy check that it actually has an non null eResource(). It doesn't make sense to export dangling references. This problem should actually be caught during validation, but at that point it is already too late. The reference has already been added to the builder state. So I propose to change: protected boolean isResolvedAndExternal(EObject from, EObject to) { if (to == null) return false; if (!to.eIsProxy()) return from.eResource() != to.eResource(); return !getLazyURIEncoder() .isCrossLinkFragment(from.eResource(), ((InternalEObject) to).eProxyURI().fragment()); } to: protected boolean isResolvedAndExternal(EObject from, EObject to) { if (to == null) return false; if (!to.eIsProxy()) { if (to.eResource() == null) { LOG.error("Reference from " + EcoreUtil.getURI(from) + " to " + to + " cannot be exported as the target is not contained in a resource."); return false; } return from.eResource() != to.eResource(); } return !getLazyURIEncoder() .isCrossLinkFragment(from.eResource(), ((InternalEObject) to).eProxyURI().fragment()); }
+1
I wonder where the dangling references come from in the first place. However, since the cannot provide reasonable uris it's a good idea to filter them.
The use case is admittedly a bit dubious: A derived reference which in its implementation returned on-the-fly created EObjects, which weren't contained anywhere. Additionally the default EObjectValidator which checks for this kind of problem (in validate_EveryReferenceIsContained()) was disabled for performance reasons. I believe that this kind of error should only be possible if the language implementor has done something wrong. Not because of a mistake of the user. That's why we also decided to disable this validation as it has a nasty side effect: It causes all proxies, which we've been so careful to maintain, to be resolved. The additional check and logged error in isResolvedAndExternal() thus also doubles as a substitute for the validation. An alternative would of course be to modify the validation to only emit diagnostics for this specific case; without resolving any proxies.
The additional guard as proposed is perfectly ok.
Pushed fix to master.
Closing all bugs that were set to RESOLVED before Neon.0