Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Strange behavior from the Registry(Registry returning incorrect EPackage for namespace)
Strange behavior from the Registry [message #556770] Thu, 02 September 2010 14:58 Go to next message
Nathan T. Freeman is currently offline Nathan T. FreemanFriend
Messages: 2
Registered: September 2010
Junior Member
I have a plugin with 5 EPackages: Xhtml, F, Xc, Xe and Xp. Each has a unique namespace. There are a considerable number of interdependencies between these packages.

One of the getters in my "Xp" package looks like the following...
xsp_IncludeCompositeEClass = (EClass) EPackage.Registry.INSTANCE.getEPackage(XpPackage.eNS_URI).getEClassifiers().get(145);


However, I was always getting a ClassCastException because it wasn't returning an EClass instance but an EEnumImpl instance.

Upon digging, I discovered that the .getEPackage(XpPackage.eNS_URI) call was actually returning the XePackage instance. This is very strange, because the XpPackage clearly states...
String eNS_URI = "http://www.ibm.com/xsp/core";


...while the XePackage clearly states...
String eNS_URI = "http://www.ibm.com/xsp/coreex";


I thought perhaps it might be the extension points, so I checked those...
 <extension point="org.eclipse.emf.ecore.generated_package">
      <package
            uri="http://www.ibm.com/xsp/core"
            class="com.gbs.transmogrifier.model.xp.meta.XpPackage"
            genModel="model/xsp.genmodel"/>
   </extension>
   <extension point="org.eclipse.emf.ecore.generated_package">
      <package
            uri="http://www.ibm.com/xsp/coreex"
            class="com.gbs.transmogrifier.model.xe.meta.XePackage"
            genModel="model/xsp.genmodel"/>
   </extension>


Everything looks okay to me. So I threw some diagnostics into the generated code, so I could see what the Registry looked like at runtime...

http://www.w3.org/1999/xhtml returns xe
http://www.ibm.com/xsp/coreex returns xe
http://www.ibm.com/xsp/core returns xe
http://www.ibm.com/xsp/custom returns xc

As you can see, the Xe package has somehow managed to hijack the namespaces of 3 other packages. I don't understand how this could happen, and I'm desperate for any insight as to a cause.

Thank you.
Re: Strange behavior from the Registry [message #556791 is a reply to message #556770] Thu, 02 September 2010 15:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010109080505070008050400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Nathan,

Comments below.


Nathan T. Freeman wrote:
> I have a plugin with 5 EPackages: Xhtml, F, Xc, Xe and Xp. Each has a
> unique namespace. There are a considerable number of
> interdependencies between these packages.
>
> One of the getters in my "Xp" package looks like the following...
> xsp_IncludeCompositeEClass = (EClass)
> EPackage.Registry.INSTANCE.getEPackage(XpPackage.eNS_URI).ge tEClassifiers().get(145);
>
>
> However, I was always getting a ClassCastException because it wasn't
> returning an EClass instance but an EEnumImpl instance.
>
> Upon digging, I discovered that the .getEPackage(XpPackage.eNS_URI)
> call was actually returning the XePackage instance. This is very
> strange, because the XpPackage clearly states...
> String eNS_URI = "http://www.ibm.com/xsp/core";
>
> ..while the XePackage clearly states...
> String eNS_URI = "http://www.ibm.com/xsp/coreex";
>
> I thought perhaps it might be the extension points, so I checked those...
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri="http://www.ibm.com/xsp/core"
> class="com.gbs.transmogrifier.model.xp.meta.XpPackage"
> genModel="model/xsp.genmodel"/>
> </extension>
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri="http://www.ibm.com/xsp/coreex"
> class="com.gbs.transmogrifier.model.xe.meta.XePackage"
> genModel="model/xsp.genmodel"/>
> </extension>
>
If there are conflicting registrations, then this code in
GeneratedPackageRegistryReader should log a message so check for that.

Object previous = EPackage.Registry.INSTANCE.put(packageURI, new
EPackageDescriptor(element, ATT_CLASS));
if (previous instanceof PluginClassDescriptor)
{
PluginClassDescriptor descriptor =
(PluginClassDescriptor)previous;
EcorePlugin.INSTANCE.log
("Both '" + descriptor.element.getContributor().getName() +
"' and '" + element.getContributor().getName() + "' register a package
for '" + packageURI + "'");
}

It's also possible that something is programmatically updating the
registry. A conditional breakpoint in HashMap.put looking for a
namespace that's been stomped would help.
>
> Everything looks okay to me. So I threw some diagnostics into the
> generated code, so I could see what the Registry looked like at
> runtime...
>
> http://www.w3.org/1999/xhtml returns xe
> http://www.ibm.com/xsp/coreex returns xe
> http://www.ibm.com/xsp/core returns xe
> http://www.ibm.com/xsp/custom returns xc
>
> As you can see, the Xe package has somehow managed to hijack the
> namespaces of 3 other packages. I don't understand how this could
> happen, and I'm desperate for any insight as to a cause.
>
> Thank you.

--------------010109080505070008050400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Nathan,<br>
<br>
Comments below.<br>
<br>
<br>
Nathan T. Freeman wrote:
<blockquote cite="mid:i5oe3j$aqq$1@build.eclipse.org" type="cite">I
have a plugin with 5 EPackages: Xhtml, F, Xc, Xe and Xp. Each has a
unique namespace.  There are a considerable number of interdependencies
between these packages.
<br>
<br>
One of the getters in my "Xp" package looks like the following...
<br>
xsp_IncludeCompositeEClass = (EClass)
EPackage.Registry.INSTANCE.getEPackage(XpPackage.eNS_URI).ge tEClassifiers().get(145);
<br>
<br>
However, I was always getting a ClassCastException because it wasn't
returning an EClass instance but an EEnumImpl instance.
<br>
<br>
Upon digging, I discovered that the .getEPackage(XpPackage.eNS_URI)
call was actually returning the XePackage instance.  This is very
strange, because the XpPackage clearly states...
<br>
String eNS_URI = <a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/xsp/core">"http://www.ibm.com/xsp/core"</a>;
<br>
<br>
...while the XePackage clearly states...
<br>
String eNS_URI = <a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/xsp/coreex">"http://www.ibm.com/xsp/coreex"</a>;
<br>
<br>
I thought perhaps it might be the extension points, so I checked
those...
<br>
&lt;extension point="org.eclipse.emf.ecore.generated_package"&gt;
<br>
     &lt;package
<br>
           uri=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/xsp/core">"http://www.ibm.com/xsp/core"</a>
<br>
           class="com.gbs.transmogrifier.model.xp.meta.XpPackage"
<br>
           genModel="model/xsp.genmodel"/&gt;
<br>
  &lt;/extension&gt;
<br>
  &lt;extension point="org.eclipse.emf.ecore.generated_package"&gt;
<br>
     &lt;package
<br>
           uri=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/xsp/coreex">"http://www.ibm.com/xsp/coreex"</a>
<br>
           class="com.gbs.transmogrifier.model.xe.meta.XePackage"
<br>
           genModel="model/xsp.genmodel"/&gt;
<br>
  &lt;/extension&gt;
<br>
<br>
</blockquote>
If there are conflicting registrations, then this code in
GeneratedPackageRegistryReader should log a message so check for that.<br>
<br>
<small>        Object previous =
EPackage.Registry.INSTANCE.put(packageURI, new
EPackageDescriptor(element, ATT_CLASS));<br>
        if (previous instanceof PluginClassDescriptor)<br>
        {<br>
          PluginClassDescriptor descriptor =
(PluginClassDescriptor)previous;<br>
          EcorePlugin.INSTANCE.log<br>
            ("Both '" + descriptor.element.getContributor().getName() +
"' and '" + element.getContributor().getName() + "' register a package
for '" + packageURI + "'");<br>
        }</small><br>
<br>
It's also possible that something is programmatically updating the
registry.  A conditional breakpoint in HashMap.put looking for a
namespace that's been stomped would help.<br>
<blockquote cite="mid:i5oe3j$aqq$1@build.eclipse.org" type="cite"><br>
Everything looks okay to me. So I threw some diagnostics into the
generated code, so I could see what the Registry looked like at
runtime...
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a> returns xe
<br>
<a class="moz-txt-link-freetext" href="http://www.ibm.com/xsp/coreex">http://www.ibm.com/xsp/coreex</a> returns xe
<br>
<a class="moz-txt-link-freetext" href="http://www.ibm.com/xsp/core">http://www.ibm.com/xsp/core</a> returns xe
<br>
<a class="moz-txt-link-freetext" href="http://www.ibm.com/xsp/custom">http://www.ibm.com/xsp/custom</a> returns xc
<br>
<br>
As you can see, the Xe package has somehow managed to hijack the
namespaces of 3 other packages.  I don't understand how this could
happen, and I'm desperate for any insight as to a cause.
<br>
<br>
Thank you.
<br>
</blockquote>
</body>
</html>

--------------010109080505070008050400--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Strange behavior from the Registry [message #557052 is a reply to message #556791] Fri, 03 September 2010 19:16 Go to previous messageGo to next message
Nathan T. Freeman is currently offline Nathan T. FreemanFriend
Messages: 2
Registered: September 2010
Junior Member
Ed, thanks so much for your prompt reply.

There's definitely no error log indicating a conflicting namespace. And I tried your suggestion of a conditional breakpoint on HashMap.put, but that didn't yield any new information.

I also tried explicitly re-registering to the proper namespaces, but couldn't get that to work because instantiating the existing EPackages threw the same errors because of the existing registrations.

Since then, I've been worming my way through the code step by step, and I've noticed something surprising. None of the corresponding EFactories are registered. So all the appropriate keys are in the Registry, but .getEFactory() for any of my namespaces returns null, and fails over to the new instance.

Is there some additional extension point that I should be using to register the Factories?
Re: Strange behavior from the Registry [message #557067 is a reply to message #557052] Fri, 03 September 2010 22:11 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Nathan,

Which version of EMF are you using?

So you've set breakpoints in getEPackage and watched how descriptors are
resolved? The only calls to put things in the registry should be the
extension point reader, the getEPackage method when the descriptor is
being resolved, and in the XyzPackageImpl.init method. It's hard to
imagine how any of these end up registering the wrong package...


Nathan T. Freeman wrote:
> Ed, thanks so much for your prompt reply.
>
> There's definitely no error log indicating a conflicting namespace.
> And I tried your suggestion of a conditional breakpoint on
> HashMap.put, but that didn't yield any new information.
>
> I also tried explicitly re-registering to the proper namespaces, but
> couldn't get that to work because instantiating the existing EPackages
> threw the same errors because of the existing registrations.
>
> Since then, I've been worming my way through the code step by step,
> and I've noticed something surprising. None of the corresponding
> EFactories are registered. So all the appropriate keys are in the
> Registry, but .getEFactory() for any of my namespaces returns null,
> and fails over to the new instance.
>
> Is there some additional extension point that I should be using to
> register the Factories?


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Setting content for EcoreEditor
Next Topic:Turning off Mint
Goto Forum:
  


Current Time: Thu Mar 28 23:14:36 GMT 2024

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

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

Back to the top