Home » Modeling » EMF » [EMF] BinaryResourceImpl uses globale package registry, not the registry of its resource set
|
Re: [EMF] BinaryResourceImpl uses globale package registry, not the registry of its resource set [message #1015949 is a reply to message #1015944] |
Mon, 04 March 2013 11:45 |
Ed Merks Messages: 33107 Registered: July 2009 |
Senior Member |
|
|
Markus,
Yes, that looks a little inconsistent, but isn't it the case that
resourceSet.getEObject(uri, true) will find it? Or is it the case that
are you trying to override a global registration in your local resource
set, because that's definitely being bypassed and seems inconsistent...
On 04/03/2013 12:19 PM, Markus Scheidgen wrote:
> When loading, BinaryResourceImpl resolves package URIs only with the
> global package registry (EPackage.Registry.INSTANCE), even if the
> resource is part of a resource set. Shouldn't it use the resource sets
> registry ResourceSet#getPackageRegistry() instead? Bug or feature? Is
> there a work around?
>
> The current
> http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/impl/BinaryResourceImpl.java
> (git master, head)
> line: 1405
>
> protected EPackageData readEPackage() throws IOException
> {
> int id = readCompressedInt();
> if (ePackageDataList.size() <= id)
> {
> EPackageData ePackageData = new EPackageData();
> String nsURI = readString();
> URI uri = readURI();
> if (resourceSet != null)
> {
> ePackageData.ePackage =
> EPackage.Registry.INSTANCE.getEPackage(nsURI);
> if (ePackageData.ePackage == null)
> {
> ePackageData.ePackage =
> (EPackage)resourceSet.getEObject(uri, true);
> }
> }
> else
> {
> ePackageData.ePackage =
> EPackage.Registry.INSTANCE.getEPackage(nsURI);
> }
> ePackageData.eClassData = new EClassData
> [ePackageData.ePackage.getEClassifiers().size()];
> ePackageDataList.add(ePackageData);
> return ePackageData;
> }
> else
> {
> return ePackageDataList.get(id);
> }
> }
>
>
> Thx,
> Markus
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [EMF] BinaryResourceImpl uses globale package registry, not the registry of its resource set [message #1015973 is a reply to message #1015949] |
Mon, 04 March 2013 12:58 |
Markus Scheidgen Messages: 7 Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
you are right in both cases: resourceSet.getEObject(uri, true) resolves the package via resourceSet.getPackageRegistry as long as the global registry does not contain a corresponding entry. But as you guessed, I overloaded the global registry, i.e. different packages in both registries with the same nsURI. I grant that my use case is rather unusual, but never the less I tripped. It doesn't bother me that much though: I can overload the default behavior by extending BinaryResourceImpl and its inner class EObjectInputStream. But these kinda hacks are always a little ugly, since it creates a dependency towards internals that might change with future versions of EMF. Anyways, I just thought a give a pointer to a potential (small) bug (or Bug-chen, as we say in germany).
Thx for not making anything private/final/internal, adds a lot of flexibility .
Markus
|
|
|
Re: [EMF] BinaryResourceImpl uses globale package registry, not the registry of its resource set [message #1015977 is a reply to message #1015973] |
Mon, 04 March 2013 13:08 |
Ed Merks Messages: 33107 Registered: July 2009 |
Senior Member |
|
|
Markus,
It does seem inconsistent not to consult the resource set's package
registry rather than go directly to the global package registry so
please open a bugzilla and I'll address this in 2.9.
On 04/03/2013 1:58 PM, Markus Scheidgen wrote:
> Hi Ed,
>
> you are right in both cases: resourceSet.getEObject(uri, true)
> resolves the package via resourceSet.getPackageRegistry as long as the
> global registry does not contain a corresponding entry. But as you
> guessed, I overloaded the global registry, i.e. different packages in
> both registries with the same nsURI. I grant that my use case is
> rather unusual, but never the less I tripped. It doesn't bother me
> that much though: I can overload the default behavior by extending
> BinaryResourceImpl and its inner class EObjectInputStream. But these
> kinda hacks are always a little ugly, since it creates a dependency
> towards internals that might change with future versions of EMF.
> Anyways, I just thought a give a pointer to a potential (small) bug
> (or Bug-chen, as we say in germany).
>
> Thx for not making anything private/final/internal, adds a lot of
> flexibility :).
> Markus
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Tue Mar 19 04:02:58 GMT 2024
Powered by FUDForum. Page generated in 0.02876 seconds
|