Eclipse Community Forums: EMF » Fail to get inherited EAttribute with Resource.getObject(String uriFragment)

Help

Home

Home » Modeling » EMF » Fail to get inherited EAttribute with Resource.getObject(String uriFragment)

Show: Today's Messages :: Show Polls :: Message Navigator

Fail to get inherited EAttribute with Resource.getObject(String uriFragment) [message #1818757]

Fri, 27 December 2019 10:56

Fabien Giquel

Messages: 147
Registered: July 2009

Senior Member

Hi everyone,

I encounter the following problem, both with old org.eclipse.emf.ecore old 2.12 or more recent 2.19.
I create a EPackage dynamically and register it in EPackage.Registry (i.e. no genmodel). There is a EClass "A" defining a EAttribute "name", and a EClass "B" inheriting from "A".

Test1 : When I first try to get the "name" EAttribute with Resource#getObject("/0/B/name") (invoked on resource containing dynamic EPackage instance) -> I obtain null.
Test2: after a sequence of various other invocations, including EClass#getEStructuralFeature(...) on B, a new try on Resource#getObject("/0/B/name") will success in giving the "name" EAttribute.

Debugging into the Resource#getObject(..) brings me to EClassImpl#eObjectForURIFragmentSegment(String uriFragmentSegment) code. If "eAllStructuralFeaturesData" cache has been initialized before ("Test2" case), we get the result from getEStructuralFeature(..). Else ("Test1" case) the code delegates to super.eObjectForURIFragmentSegment(..) which searches on direct contained features (from B) but not on super types (like A).

Is it a wrong idea to try to get "name" from uri "/0/B/name" rather than "/0/A/name" ?
For now i have a simple workaround in adding a loop of "useless" EClass#getEAllStructuralFeatures() invocations, just after dynamic EPackage creation.

Thanks for help.

----------------------------------------------------
Fabien GIQUEL
R&D Engineer
Mia-Software
rue Nina Simone
44000 NANTES
----------------------------------------------------

Report message to a moderator

Re: Fail to get inherited EAttribute with Resource.getObject(String uriFragment) [message #1818759 is a reply to message #1818757]

Fri, 27 December 2019 12:45

Ed Merks

Messages: 30898
Registered: July 2009

Senior Member

Technically it's not 100% correct that the optimization in eObjectForURIFragmentSegment that calls getEStructuralFeature ever returns a feature that isn't contained by the EClass instance. But no serializer would ever produce that fragment path in the first place., because a reference to the feature "name" would build a fragment path that navigates though "A" not through "B". But the context of your question is missing, i.e., where does a path like "/0/B/name" come from in the first place? That isn't a good idea and you should not try to get it to work with workarounds but rather should avoid this.

Report message to a moderator

Re: Fail to get inherited EAttribute with Resource.getObject(String uriFragment) [message #1818761 is a reply to message #1818759]

Fri, 27 December 2019 14:37

Fabien Giquel

Messages: 147
Registered: July 2009

Senior Member

Thanks for the explanation,

"/0/B/name" kind of path is produced by one of our tool which iterates on all attributes for some EClasses. It produces automatically some EMFFacet model where one FacetAttribute references indirectly one EAttribute by this "/0/B/name" path.
The mechanism has worked for a long time. The bad practice is now revealed since we have changed from java generated to dynamic EPackage.
I will see in our tool implementation to fix it.

Regards,

----------------------------------------------------
Fabien GIQUEL
R&D Engineer
Mia-Software
rue Nina Simone
44000 NANTES
----------------------------------------------------

Report message to a moderator

Previous Topic:	Behaviors for proxy contained in containment feature after
Next Topic:	Ecore Inheritance in the same Namespace

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Feb 24 09:33:44 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter