|
|
|
| Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423489 is a reply to message #423479] |
Wed, 01 October 2008 10:52   |
 Ed Merks
Messages: 33140
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
>>>
>>>
>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423559 is a reply to message #423545] |
Thu, 02 October 2008 11:47 |
Ed Merks
Messages: 33140
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: NPE in EPackageImpl.initializeFromLoadedEPackage when loadInitialization="tr [message #423610 is a reply to message #423559] |
Thu, 02 October 2008 23:48 |
Andrew H
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
>>
|
|
|
Powered by
FUDForum. Page generated in 0.03364 seconds
] 
Search
Help
Register
Login
Home
