Eclipse Community Forums: EMF » Global EMF Registry

Help

Home

Home » Modeling » EMF » Global EMF Registry

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

Global EMF Registry [message #664049]

Thu, 07 April 2011 10:02

Enrico Biermann

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

Report message to a moderator

Re: Global EMF Registry [message #664130 is a reply to message #664049]

Thu, 07 April 2011 14:22

Ed Merks

Messages: 33140
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

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Global EMF Registry [message #664179 is a reply to message #664049]

Thu, 07 April 2011 18:09

Enrico Biermann

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

Report message to a moderator

Re: Global EMF Registry [message #664204 is a reply to message #664179]

Thu, 07 April 2011 19:48

Ed Merks

Messages: 33140
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

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

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:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 04:33:04 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter