Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Global EMF Registry
Global EMF Registry [message #664049] Thu, 07 April 2011 10:02 Go to next message
Enrico Biermann is currently offline Enrico BiermannFriend
Messages: 2
Registered: April 2011
Junior Member
Hello,

I am confused about the global EMF registry. I assumed that all other registries will eventually refer to the global registry via delegateRegistry.

However there are three additional registries created that don't use the global registry:
XMLContentHandler creates one when initializing its ExtendedMetaData field with BasicExtendedMetadata
BasicExtendedMetaData creates another "demandRegistry" and is used twice (XMLContentHandler and FeatureMapUtil).

The problem is when browsing and opening files, EMF-compatible files are examined and their EPackages are registered with the demandRegistry of the BasicExtendedMetaData from the XMLContentHandler. The problem is, if at any point I want to use the global registry to lookup an nsUri (either automatically by trying to resolve a proxy or manually via get(nsUri) it will fail because the global registry is unaware of the other registries. In such a case the global registry will create a new EPackage and registers it with the same nsUri used in the other registry.

My problem is that I later want to compare eClasses from the resolved proxy and those loaded from a file however they belong to different EPackages (one from the global registry and one from the demandRegistry from XMLContentHandler.extendedMetaData).

Regards,
Enrico
Re: Global EMF Registry [message #664130 is a reply to message #664049] Thu, 07 April 2011 14:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Enrico,

Comments below.

Enrico Biermann wrote:
> Hello,
>
> I am confused about the global EMF registry. I assumed that all other
> registries will eventually refer to the global registry via
> delegateRegistry.
>
> However there are three additional registries created that don't use
> the global registry:
> XMLContentHandler creates one when initializing its ExtendedMetaData
> field with BasicExtendedMetadata
Yes, because it reads XML purely for the purposes of determining the
namespaces which are then used to determine an appropriate content
type. It does not need to know about any registered packages and
shouldn't activate those bundles even if corresponding packages are
available.
> BasicExtendedMetaData creates another "demandRegistry" and is used
> twice (XMLContentHandler and FeatureMapUtil).
Yes, that's to deal with content information specific to that one XML
instance.
>
> The problem is when browsing and opening files, EMF-compatible files
> are examined and their EPackages are registered with the
> demandRegistry of the BasicExtendedMetaData from the XMLContentHandler.
Just enough metadata is created to represent the XML.
> The problem is, if at any point I want to use the global registry to
> lookup an nsUri (either automatically by trying to resolve a proxy or
> manually via get(nsUri) it will fail because the global registry is
> unaware of the other registries.
It's intentional that these other registries provide isolation. The
global package registry should only include packages registered via
extensions in the plugin.xml.
> In such a case the global registry will create a new EPackage and
> registers it with the same nsUri used in the other registry.
The global registry should only ever contain the one EPackage instance
that everyone is intended to share.
>
> My problem is that I later want to compare eClasses from the resolved
> proxy and those loaded from a file however they belong to different
> EPackages (one from the global registry and one from the
> demandRegistry from XMLContentHandler.extendedMetaData).
The content handler should be used only for determining content type.
The resource loaded from it should not be used for any other purposes.
>
> Regards,
> Enrico
Re: Global EMF Registry [message #664179 is a reply to message #664049] Thu, 07 April 2011 18:09 Go to previous messageGo to next message
Enrico Biermann is currently offline Enrico BiermannFriend
Messages: 2
Registered: April 2011
Junior Member
Hello Ed,

thanks for your response. I don't use generated code in this case and therefore don't have this package in the global registry (except when I register it manually). My problem is that in one case (file) the EClasses from the demandRegistry is used to create EObjects and in the other case (proxy) the global registry is used. For both cases an EPackage is created if it did not already exist in the specific registry.

I don't want to use the content handler or its registry (it is protected anyway), but EMF is using it when loading such an xmi-file. Is there any way to provide the *real* EPackage when opening such files or change the content handlers strategy to find a valid EPackage ("don't look in the metadata registries but use the global one")?

Regards,
Enrico
Re: Global EMF Registry [message #664204 is a reply to message #664179] Thu, 07 April 2011 19:48 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Enrico,

Comments below.

Enrico Biermann wrote:
> Hello Ed,
>
> thanks for your response. I don't use generated code in this case and
> therefore don't have this package in the global registry (except when
> I register it manually). My problem is that in one case (file) the
> EClasses from the demandRegistry is used to create EObjects
That would happen only if you've not registered the package in the
global package registry or the package registry in the resource set
you're using the load the instance.
> and in the other case (proxy) the global registry is used.
Proxies are just created EObjects, so I'm not sure I understand which
case is which.
> For both cases an EPackage is created if it did not already exist in
> the specific registry.
Depending on the option that might well be the case.
>
> I don't want to use the content handler or its registry (it is
> protected anyway), but EMF is using it when loading such an xmi-file.
I don't understand how what the content handler does affects the loading
of your instances.
> Is there any way to provide the *real* EPackage when opening such
> files or change the content handlers strategy to find a valid EPackage
> ("don't look in the metadata registries but use the global one")?
You can register your packages in the resource set's package registry.
>
> Regards,
> Enrico
Previous Topic:EMF Show model attributes as rows in a table/tree
Next Topic:'src' folder appears empty in Package Explorer view after EMF Java generation
Goto Forum:
  


Current Time: Fri Oct 18 03:28:21 GMT 2019

Powered by FUDForum. Page generated in 0.02779 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top