Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="true"
NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="true" [message #423408] Tue, 30 September 2008 07:48 Go to next message
Andrew H is currently offline Andrew HFriend
Messages: 117
Registered: July 2009
Senior Member
I would raise a bugzilla for this if I could get bugzilla to work...

I get a NPE when trying referring to a package via MyPackage.eInstance as
a result of a loadInitialization="true" being set in the genmodel.

The genmodel that was created using the wizard had
loadInitialization="true" on one of the packages. I did not set this, it
was automatically set by the wizard.

The package in question was one of the packages generated from some
industry XSD's so the reason for the wizard setting this flag may relate
to this origin.

This has resulted in a NullPointerException when I try to reference
MyPackage.eInstance.

I have been able to reproduce this in a very simple model by explicitly
setting loadInitialization="true". That example is included below.

A workaround for me is to set this flag to false, but I am unsure what the
implications of this might be. Presumably the wizard set this flag for a
reason.

I don't believe this is the same as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=179561 but I could be wrong.

Simple example to reproduce the problem

---
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="a"
nsURI="urn:a/1.0" nsPrefix="a">
<eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
instanceClassName="java.lang.String"/>
<eSubpackages href="a/b.ecore#/"/>
<eSubpackages href="a/c.ecore#/"/>
</ecore:EPackage>

---

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="b"
nsURI="urn:b/1.0" nsPrefix="b">
<eClassifiers xsi:type="ecore:EClass" name="B">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="B"/>
<details key="kind" value="elementOnly"/>
</eAnnotations>
<eStructuralFeatures xsi:type="ecore:EReference" name="d"
eType="ecore:EClass c/d.ecore#//D"/>
</eClassifiers>
</ecore:EPackage>


---

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="c"
nsURI="urn:c/1.0" nsPrefix="c">
<eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
instanceClassName="java.lang.String"/>
<eSubpackages href="c/d.ecore#/"/>
</ecore:EPackage>



--

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="d"
nsURI="urn:d/1.0" nsPrefix="d">
<eClassifiers xsi:type="ecore:EClass" name="D"/>
</ecore:EPackage>


----

<?xml version="1.0" encoding="UTF-8"?>
<genmodel:GenModel xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel"
modelDirectory="/TestLibaryModel/src"
modelPluginID="TestLibaryModel" modelName="A"
importerID="org.eclipse.emf.importer.ecore"
complianceLevel="5.0" copyrightFields="false">
<foreignModel>a.ecore</foreignModel>
<genPackages prefix="A" disposableProviderFactory="true"
loadInitialization="true"
ecorePackage="a.ecore#/">
<genDataTypes ecoreDataType="a.ecore#//DummyDataType"/>
<nestedGenPackages prefix="B" basePackage="a"
disposableProviderFactory="true"
ecorePackage="a/b.ecore#/">
<genClasses ecoreClass="a/b.ecore#//B">
<genFeatures notify="false" createChild="false"
propertySortChoices="true"
ecoreFeature="ecore:EReference a/b.ecore#//B/d"/>
</genClasses>
</nestedGenPackages>
<nestedGenPackages prefix="C" basePackage="a"
disposableProviderFactory="true"
ecorePackage="a/c.ecore#/">
<genDataTypes ecoreDataType="a/c.ecore#//DummyDataType"/>
<nestedGenPackages prefix="D" basePackage="a.c"
disposableProviderFactory="true"
ecorePackage="a/c/d.ecore#/">
<genClasses ecoreClass="a/c/d.ecore#//D"/>
</nestedGenPackages>
</nestedGenPackages>
</genPackages>
</genmodel:GenModel>


---

The exception is

Exception in thread "main" java.lang.ExceptionInInitializerError
at a.c.impl.CPackageImpl.init(CPackageImpl.java:101)
at a.c.CPackage.<clinit>(CPackage.java:58)
at a.b.impl.BPackageImpl.init(BPackageImpl.java:97)
at a.b.BPackage.<clinit>(BPackage.java:59)
at a.impl.APackageImpl.init(APackageImpl.java:111)
at a.APackage.<clinit>(APackage.java:58)
at testa.TestA.main(TestA.java:8)
Caused by: java.lang.NullPointerException
at
org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1582)
at
org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1592)
at a.impl.APackageImpl.loadPackage(APackageImpl.java:180)
at a.c.d.impl.DPackageImpl.init(DPackageImpl.java:100)
at a.c.d.DPackage.<clinit>(DPackage.java:58)
... 7 more
Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="true" [message #423414 is a reply to message #423408] Tue, 30 September 2008 09:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30802
Registered: July 2009
Senior Member
Andrew,

What version of EMF are you using? It sounds similar to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=242494 though I see you
have dummy classifiers which should avoid the problem. However, note
that load initialization is a GenPackage setting and you've set it true
on only one of the packages. I think the above bugzilla fixed the
problems associated with not having a consistent setting for that across
the contains subpackages. In any case, you should be able to avoid this
by setting it to false (given that you are creating smaller packages).


Andrew H wrote:
> I would raise a bugzilla for this if I could get bugzilla to work...
>
> I get a NPE when trying referring to a package via MyPackage.eInstance
> as a result of a loadInitialization="true" being set in the genmodel.
>
> The genmodel that was created using the wizard had
> loadInitialization="true" on one of the packages. I did not set this,
> it was automatically set by the wizard.
>
> The package in question was one of the packages generated from some
> industry XSD's so the reason for the wizard setting this flag may
> relate to this origin.
>
> This has resulted in a NullPointerException when I try to reference
> MyPackage.eInstance.
>
> I have been able to reproduce this in a very simple model by
> explicitly setting loadInitialization="true". That example is included
> below.
>
> A workaround for me is to set this flag to false, but I am unsure what
> the implications of this might be. Presumably the wizard set this flag
> for a reason.
>
> I don't believe this is the same as
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=179561 but I could be
> wrong.
>
> Simple example to reproduce the problem
>
> ---
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="a"
> nsURI="urn:a/1.0" nsPrefix="a">
> <eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
> instanceClassName="java.lang.String"/>
> <eSubpackages href="a/b.ecore#/"/>
> <eSubpackages href="a/c.ecore#/"/>
> </ecore:EPackage>
>
> ---
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="b"
> nsURI="urn:b/1.0" nsPrefix="b">
> <eClassifiers xsi:type="ecore:EClass" name="B">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="name" value="B"/>
> <details key="kind" value="elementOnly"/>
> </eAnnotations>
> <eStructuralFeatures xsi:type="ecore:EReference" name="d"
> eType="ecore:EClass c/d.ecore#//D"/>
> </eClassifiers>
> </ecore:EPackage>
>
>
> ---
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="c"
> nsURI="urn:c/1.0" nsPrefix="c">
> <eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
> instanceClassName="java.lang.String"/>
> <eSubpackages href="c/d.ecore#/"/>
> </ecore:EPackage>
>
>
>
> --
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="d"
> nsURI="urn:d/1.0" nsPrefix="d">
> <eClassifiers xsi:type="ecore:EClass" name="D"/>
> </ecore:EPackage>
>
>
> ----
>
> <?xml version="1.0" encoding="UTF-8"?>
> <genmodel:GenModel xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel"
> modelDirectory="/TestLibaryModel/src"
> modelPluginID="TestLibaryModel" modelName="A"
> importerID="org.eclipse.emf.importer.ecore"
> complianceLevel="5.0" copyrightFields="false">
> <foreignModel>a.ecore</foreignModel>
> <genPackages prefix="A" disposableProviderFactory="true"
> loadInitialization="true"
> ecorePackage="a.ecore#/">
> <genDataTypes ecoreDataType="a.ecore#//DummyDataType"/>
> <nestedGenPackages prefix="B" basePackage="a"
> disposableProviderFactory="true"
> ecorePackage="a/b.ecore#/">
> <genClasses ecoreClass="a/b.ecore#//B">
> <genFeatures notify="false" createChild="false"
> propertySortChoices="true"
> ecoreFeature="ecore:EReference a/b.ecore#//B/d"/>
> </genClasses>
> </nestedGenPackages>
> <nestedGenPackages prefix="C" basePackage="a"
> disposableProviderFactory="true"
> ecorePackage="a/c.ecore#/">
> <genDataTypes ecoreDataType="a/c.ecore#//DummyDataType"/>
> <nestedGenPackages prefix="D" basePackage="a.c"
> disposableProviderFactory="true"
> ecorePackage="a/c/d.ecore#/">
> <genClasses ecoreClass="a/c/d.ecore#//D"/>
> </nestedGenPackages>
> </nestedGenPackages>
> </genPackages>
> </genmodel:GenModel>
>
>
> ---
>
> The exception is
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at a.c.impl.CPackageImpl.init(CPackageImpl.java:101)
> at a.c.CPackage.<clinit>(CPackage.java:58)
> at a.b.impl.BPackageImpl.init(BPackageImpl.java:97)
> at a.b.BPackage.<clinit>(BPackage.java:59)
> at a.impl.APackageImpl.init(APackageImpl.java:111)
> at a.APackage.<clinit>(APackage.java:58)
> at testa.TestA.main(TestA.java:8)
> Caused by: java.lang.NullPointerException
> at
> org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1582)
>
> at
> org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1592)
>
> at a.impl.APackageImpl.loadPackage(APackageImpl.java:180)
> at a.c.d.impl.DPackageImpl.init(DPackageImpl.java:100)
> at a.c.d.DPackage.<clinit>(DPackage.java:58)
> ... 7 more
>
>
>
>
>
Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423479 is a reply to message #423414] Tue, 30 September 2008 23:59 Go to previous messageGo to next message
Andrew H is currently offline Andrew HFriend
Messages: 117
Registered: July 2009
Senior Member
Yeah I'd say it definitely relates in some way to that issue.

At least I understand now what causes the switch to loading an ecore file
vs creating the contents in Java - its the size of the package.
Unsurprisingly the package in question is one of the larger ones from my
initial refactoring of the model generated from the industry XSD's.

And since it compiled OK after I changed this flag to false I can be
comfortable that there are no other side effects. As I did not know why
the different approaches were used I had no idea whether there would be a
price to pay for changing this flag.

Note in my real application I never set this flag. It was set by the
wizard somehow. It was only set on the one package there so I did a
similar thing in my example gen model.

So it would appear that there is still a bug here somewhere but I can move
on with this workaround. Like you said, we will only make the packages
smaller over time never bigger.

thanks

Andrew

Ed Merks wrote:

> Andrew,

> What version of EMF are you using? It sounds similar to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=242494 though I see you
> have dummy classifiers which should avoid the problem. However, note
> that load initialization is a GenPackage setting and you've set it true
> on only one of the packages. I think the above bugzilla fixed the
> problems associated with not having a consistent setting for that across
> the contains subpackages. In any case, you should be able to avoid this
> by setting it to false (given that you are creating smaller packages).


> Andrew H wrote:
>> I would raise a bugzilla for this if I could get bugzilla to work...
>>
>> I get a NPE when trying referring to a package via MyPackage.eInstance
>> as a result of a loadInitialization="true" being set in the genmodel.
>>
>> The genmodel that was created using the wizard had
>> loadInitialization="true" on one of the packages. I did not set this,
>> it was automatically set by the wizard.
>>
>> The package in question was one of the packages generated from some
>> industry XSD's so the reason for the wizard setting this flag may
>> relate to this origin.
>>
>> This has resulted in a NullPointerException when I try to reference
>> MyPackage.eInstance.
>>
>> I have been able to reproduce this in a very simple model by
>> explicitly setting loadInitialization="true". That example is included
>> below.
>>
>> A workaround for me is to set this flag to false, but I am unsure what
>> the implications of this might be. Presumably the wizard set this flag
>> for a reason.
>>
>> I don't believe this is the same as
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=179561 but I could be
>> wrong.
>>
>> Simple example to reproduce the problem
>>
>> ---
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="a"
>> nsURI="urn:a/1.0" nsPrefix="a">
>> <eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
>> instanceClassName="java.lang.String"/>
>> <eSubpackages href="a/b.ecore#/"/>
>> <eSubpackages href="a/c.ecore#/"/>
>> </ecore:EPackage>
>>
>> ---
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="b"
>> nsURI="urn:b/1.0" nsPrefix="b">
>> <eClassifiers xsi:type="ecore:EClass" name="B">
>> <eAnnotations
>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>> <details key="name" value="B"/>
>> <details key="kind" value="elementOnly"/>
>> </eAnnotations>
>> <eStructuralFeatures xsi:type="ecore:EReference" name="d"
>> eType="ecore:EClass c/d.ecore#//D"/>
>> </eClassifiers>
>> </ecore:EPackage>
>>
>>
>> ---
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="c"
>> nsURI="urn:c/1.0" nsPrefix="c">
>> <eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
>> instanceClassName="java.lang.String"/>
>> <eSubpackages href="c/d.ecore#/"/>
>> </ecore:EPackage>
>>
>>
>>
>> --
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <ecore:EPackage xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="d"
>> nsURI="urn:d/1.0" nsPrefix="d">
>> <eClassifiers xsi:type="ecore:EClass" name="D"/>
>> </ecore:EPackage>
>>
>>
>> ----
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <genmodel:GenModel xmi:version="2.0"
>> xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>> xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel"
>> modelDirectory="/TestLibaryModel/src"
>> modelPluginID="TestLibaryModel" modelName="A"
>> importerID="org.eclipse.emf.importer.ecore"
>> complianceLevel="5.0" copyrightFields="false">
>> <foreignModel>a.ecore</foreignModel>
>> <genPackages prefix="A" disposableProviderFactory="true"
>> loadInitialization="true"
>> ecorePackage="a.ecore#/">
>> <genDataTypes ecoreDataType="a.ecore#//DummyDataType"/>
>> <nestedGenPackages prefix="B" basePackage="a"
>> disposableProviderFactory="true"
>> ecorePackage="a/b.ecore#/">
>> <genClasses ecoreClass="a/b.ecore#//B">
>> <genFeatures notify="false" createChild="false"
>> propertySortChoices="true"
>> ecoreFeature="ecore:EReference a/b.ecore#//B/d"/>
>> </genClasses>
>> </nestedGenPackages>
>> <nestedGenPackages prefix="C" basePackage="a"
>> disposableProviderFactory="true"
>> ecorePackage="a/c.ecore#/">
>> <genDataTypes ecoreDataType="a/c.ecore#//DummyDataType"/>
>> <nestedGenPackages prefix="D" basePackage="a.c"
>> disposableProviderFactory="true"
>> ecorePackage="a/c/d.ecore#/">
>> <genClasses ecoreClass="a/c/d.ecore#//D"/>
>> </nestedGenPackages>
>> </nestedGenPackages>
>> </genPackages>
>> </genmodel:GenModel>
>>
>>
>> ---
>>
>> The exception is
>>
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>> at a.c.impl.CPackageImpl.init(CPackageImpl.java:101)
>> at a.c.CPackage.<clinit>(CPackage.java:58)
>> at a.b.impl.BPackageImpl.init(BPackageImpl.java:97)
>> at a.b.BPackage.<clinit>(BPackage.java:59)
>> at a.impl.APackageImpl.init(APackageImpl.java:111)
>> at a.APackage.<clinit>(APackage.java:58)
>> at testa.TestA.main(TestA.java:8)
>> Caused by: java.lang.NullPointerException
>> at
>>
org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1582)
>>
>> at
>>
org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1592)
>>
>> at a.impl.APackageImpl.loadPackage(APackageImpl.java:180)
>> at a.c.d.impl.DPackageImpl.init(DPackageImpl.java:100)
>> at a.c.d.DPackage.<clinit>(DPackage.java:58)
>> ... 7 more
>>
>>
>>
>>
>>
Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423489 is a reply to message #423479] Wed, 01 October 2008 10:52 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30802
Registered: July 2009
Senior Member
Andrew,

Comments below.

Andrew H wrote:
> Yeah I'd say it definitely relates in some way to that issue.
> At least I understand now what causes the switch to loading an ecore
> file vs creating the contents in Java - its the size of the package.
> Unsurprisingly the package in question is one of the larger ones from
> my initial refactoring of the model generated from the industry XSD's.
> And since it compiled OK after I changed this flag to false I can be
> comfortable that there are no other side effects. As I did not know
> why the different approaches were used I had no idea whether there
> would be a price to pay for changing this flag.
>
> Note in my real application I never set this flag.
Yes, it's set automatically based on the huge size. For some reason,
only XML Schema based models seem to generate such huge models. I'm not
sure what it is about schemas that tempts people into making a single
massive namespace. From this basis, one never ends up with nested
EPackages though, so it wouldn't ever lead to this kind of issue...
> It was set by the wizard somehow. It was only set on the one package
> there so I did a similar thing in my example gen model.
>
> So it would appear that there is still a bug here somewhere but I can
> move on with this workaround.
Yes, and I think the related changes addressed that...
> Like you said, we will only make the packages smaller over time never
> bigger.
>
> thanks
>
> Andrew
>
> Ed Merks wrote:
>
>> Andrew,
>
>> What version of EMF are you using? It sounds similar to
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=242494 though I see you
>> have dummy classifiers which should avoid the problem. However, note
>> that load initialization is a GenPackage setting and you've set it
>> true on only one of the packages. I think the above bugzilla fixed
>> the problems associated with not having a consistent setting for that
>> across the contains subpackages. In any case, you should be able to
>> avoid this by setting it to false (given that you are creating
>> smaller packages).
>
>
>> Andrew H wrote:
>>> I would raise a bugzilla for this if I could get bugzilla to work...
>>>
>>> I get a NPE when trying referring to a package via
>>> MyPackage.eInstance as a result of a loadInitialization="true" being
>>> set in the genmodel.
>>>
>>> The genmodel that was created using the wizard had
>>> loadInitialization="true" on one of the packages. I did not set
>>> this, it was automatically set by the wizard.
>>>
>>> The package in question was one of the packages generated from some
>>> industry XSD's so the reason for the wizard setting this flag may
>>> relate to this origin.
>>>
>>> This has resulted in a NullPointerException when I try to reference
>>> MyPackage.eInstance.
>>>
>>> I have been able to reproduce this in a very simple model by
>>> explicitly setting loadInitialization="true". That example is
>>> included below.
>>>
>>> A workaround for me is to set this flag to false, but I am unsure
>>> what the implications of this might be. Presumably the wizard set
>>> this flag for a reason.
>>>
>>> I don't believe this is the same as
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=179561 but I could be
>>> wrong.
>>>
>>> Simple example to reproduce the problem
>>>
>>> ---
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="a"
>>> nsURI="urn:a/1.0" nsPrefix="a">
>>> <eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
>>> instanceClassName="java.lang.String"/>
>>> <eSubpackages href="a/b.ecore#/"/>
>>> <eSubpackages href="a/c.ecore#/"/>
>>> </ecore:EPackage>
>>>
>>> ---
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="b"
>>> nsURI="urn:b/1.0" nsPrefix="b">
>>> <eClassifiers xsi:type="ecore:EClass" name="B">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="name" value="B"/>
>>> <details key="kind" value="elementOnly"/>
>>> </eAnnotations>
>>> <eStructuralFeatures xsi:type="ecore:EReference" name="d"
>>> eType="ecore:EClass c/d.ecore#//D"/>
>>> </eClassifiers>
>>> </ecore:EPackage>
>>>
>>>
>>> ---
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="c"
>>> nsURI="urn:c/1.0" nsPrefix="c">
>>> <eClassifiers xsi:type="ecore:EDataType" name="DummyDataType"
>>> instanceClassName="java.lang.String"/>
>>> <eSubpackages href="c/d.ecore#/"/>
>>> </ecore:EPackage>
>>>
>>>
>>>
>>> --
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ecore:EPackage xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="d"
>>> nsURI="urn:d/1.0" nsPrefix="d">
>>> <eClassifiers xsi:type="ecore:EClass" name="D"/>
>>> </ecore:EPackage>
>>>
>>>
>>> ----
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <genmodel:GenModel xmi:version="2.0"
>>> xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
>>> xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel"
>>> modelDirectory="/TestLibaryModel/src"
>>> modelPluginID="TestLibaryModel" modelName="A"
>>> importerID="org.eclipse.emf.importer.ecore"
>>> complianceLevel="5.0" copyrightFields="false">
>>> <foreignModel>a.ecore</foreignModel>
>>> <genPackages prefix="A" disposableProviderFactory="true"
>>> loadInitialization="true"
>>> ecorePackage="a.ecore#/">
>>> <genDataTypes ecoreDataType="a.ecore#//DummyDataType"/>
>>> <nestedGenPackages prefix="B" basePackage="a"
>>> disposableProviderFactory="true"
>>> ecorePackage="a/b.ecore#/">
>>> <genClasses ecoreClass="a/b.ecore#//B">
>>> <genFeatures notify="false" createChild="false"
>>> propertySortChoices="true"
>>> ecoreFeature="ecore:EReference a/b.ecore#//B/d"/>
>>> </genClasses>
>>> </nestedGenPackages>
>>> <nestedGenPackages prefix="C" basePackage="a"
>>> disposableProviderFactory="true"
>>> ecorePackage="a/c.ecore#/">
>>> <genDataTypes ecoreDataType="a/c.ecore#//DummyDataType"/>
>>> <nestedGenPackages prefix="D" basePackage="a.c"
>>> disposableProviderFactory="true"
>>> ecorePackage="a/c/d.ecore#/">
>>> <genClasses ecoreClass="a/c/d.ecore#//D"/>
>>> </nestedGenPackages>
>>> </nestedGenPackages>
>>> </genPackages>
>>> </genmodel:GenModel>
>>>
>>>
>>> ---
>>>
>>> The exception is
>>>
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>> at a.c.impl.CPackageImpl.init(CPackageImpl.java:101)
>>> at a.c.CPackage.<clinit>(CPackage.java:58)
>>> at a.b.impl.BPackageImpl.init(BPackageImpl.java:97)
>>> at a.b.BPackage.<clinit>(BPackage.java:59)
>>> at a.impl.APackageImpl.init(APackageImpl.java:111)
>>> at a.APackage.<clinit>(APackage.java:58)
>>> at testa.TestA.main(TestA.java:8)
>>> Caused by: java.lang.NullPointerException
>>> at
> org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1582)
>
>>>
>>> at
> org.eclipse.emf.ecore.impl.EPackageImpl.initializeFromLoaded EPackage(EPackageImpl.java:1592)
>
>>>
>>> at a.impl.APackageImpl.loadPackage(APackageImpl.java:180)
>>> at a.c.d.impl.DPackageImpl.init(DPackageImpl.java:100)
>>> at a.c.d.DPackage.<clinit>(DPackage.java:58)
>>> ... 7 more
>>>
>>>
>>>
>>>
>>>
>
>
Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423545 is a reply to message #423489] Thu, 02 October 2008 00:10 Go to previous messageGo to next message
Andrew H is currently offline Andrew HFriend
Messages: 117
Registered: July 2009
Senior Member
Ed Merks wrote:

>> Note in my real application I never set this flag.
> Yes, it's set automatically based on the huge size. For some reason,
> only XML Schema based models seem to generate such huge models. I'm not
> sure what it is about schemas that tempts people into making a single
> massive namespace. From this basis, one never ends up with nested
> EPackages though, so it wouldn't ever lead to this kind of issue...


I think the problem with XML is that it is human readable. Of course that
is part of its benefit too.

The problem is that because its human readable people author XML directly
in a text editor. Obviously this is not practical for binary serialisation
schemes.

Consequently, XSD authors aim to make authoring XML documents based on
those schemas easy in text editors. Having everything in one namespace
simplifies this.

It also leads to people obsessing about exactly how the XML looks and
introducing annoying concepts like substitution groups.

Personally, I think if the world moved away from this mentality with XML
to thinking in terms of a model and XML simply as a serialisation
mechanism for that model, we'd all be better off.

IMO how a model is broken down into a hierarchy of packages is as an
important part of domain modeling for a large domain model. One that is
often overlooked

my 2c
Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423559 is a reply to message #423545] Thu, 02 October 2008 11:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30802
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040708020206060701080105
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Andrew,

I agree. The obsession with pretty XML is detrimental in my opinion.
If your model has substitution groups, I'd suggest reading

http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html

As you say, large schema size is likely driven by issues related to
namespaces in instance documents, rather than the overall design being
driven by a focus on decomposition into a hierarchy of logically related
groupings.


Andrew H wrote:
> Ed Merks wrote:
>
>>> Note in my real application I never set this flag.
>> Yes, it's set automatically based on the huge size. For some reason,
>> only XML Schema based models seem to generate such huge models. I'm
>> not sure what it is about schemas that tempts people into making a
>> single massive namespace. From this basis, one never ends up with
>> nested EPackages though, so it wouldn't ever lead to this kind of
>> issue...
>
>
> I think the problem with XML is that it is human readable. Of course
> that is part of its benefit too.
> The problem is that because its human readable people author XML
> directly in a text editor. Obviously this is not practical for binary
> serialisation schemes.
>
> Consequently, XSD authors aim to make authoring XML documents based on
> those schemas easy in text editors. Having everything in one namespace
> simplifies this.
>
> It also leads to people obsessing about exactly how the XML looks and
> introducing annoying concepts like substitution groups.
>
> Personally, I think if the world moved away from this mentality with
> XML to thinking in terms of a model and XML simply as a serialisation
> mechanism for that model, we'd all be better off.
>
> IMO how a model is broken down into a hierarchy of packages is as an
> important part of domain modeling for a large domain model. One that
> is often overlooked
>
> my 2c
>

--------------040708020206060701080105
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew,<br>
<br>
I agree.
Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423610 is a reply to message #423559] Thu, 02 October 2008 23:48 Go to previous message
Andrew H is currently offline Andrew HFriend
Messages: 117
Registered: July 2009
Senior Member
Thanks Ed. I have followed that blog a few weeks ago to get things
working. Since that I have built some auto refactoring for this XSD
originated model to break it into a package hierarchy and rid it of some
of the useless XML baggage like substitution groups. We can still import
from compliant documents that use substitution groups, but our internal
model is now cleaner.

Ed Merks wrote:

> Andrew,

> I agree. The obsession with pretty XML is detrimental in my opinion.
> If your model has substitution groups, I'd suggest reading

> http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html

> As you say, large schema size is likely driven by issues related to
> namespaces in instance documents, rather than the overall design being
> driven by a focus on decomposition into a hierarchy of logically related
> groupings.


> Andrew H wrote:
>> Ed Merks wrote:
>>
>>>> Note in my real application I never set this flag.
>>> Yes, it's set automatically based on the huge size. For some reason,
>>> only XML Schema based models seem to generate such huge models. I'm
>>> not sure what it is about schemas that tempts people into making a
>>> single massive namespace. From this basis, one never ends up with
>>> nested EPackages though, so it wouldn't ever lead to this kind of
>>> issue...
>>
>>
>> I think the problem with XML is that it is human readable. Of course
>> that is part of its benefit too.
>> The problem is that because its human readable people author XML
>> directly in a text editor. Obviously this is not practical for binary
>> serialisation schemes.
>>
>> Consequently, XSD authors aim to make authoring XML documents based on
>> those schemas easy in text editors. Having everything in one namespace
>> simplifies this.
>>
>> It also leads to people obsessing about exactly how the XML looks and
>> introducing annoying concepts like substitution groups.
>>
>> Personally, I think if the world moved away from this mentality with
>> XML to thinking in terms of a model and XML simply as a serialisation
>> mechanism for that model, we'd all be better off.
>>
>> IMO how a model is broken down into a hierarchy of packages is as an
>> important part of domain modeling for a large domain model. One that
>> is often overlooked
>>
>> my 2c
>>
Previous Topic:Trouble with Proxy Resolution
Next Topic:[Teneo] Invalid Hibernate Mappings for subclasses w/ ID Fields (bugzilla 176821)
Goto Forum:
  


Current Time: Sat Jan 18 05:36:11 GMT 2020

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

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

Back to the top