Home » Modeling » EMF » ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load()
| | |
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #542631 is a reply to message #542533] |
Fri, 25 June 2010 13:41   |
 Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi,
Hm, is it possible at all to load a model based on a dynamically created
EPackage?
Since then all (pre/post/...)Load Operations should use dynamic Object
access (eGet, eSet).
Greetings,
Ralf
On 25.06.2010 10:31, Ralf Buschermoehle wrote:
> Hi Ed,
>
> On 24.06.2010 21:46, Ed Merks wrote:
>
>>> How it is possible to "convince" the ...
>>>
>>> Resource resource =
>>> reflectivStateChart.resourceManagement.resourceSet.createRes ource(fileURI);
>>>
>>>
>>> resource.load(options);
>>>
>>> ... action to use the assigned EPackage?
>> Have a look at what XMLHandler.getPackageForURI is up to. I'd expect it
>> to be using the resource set's package registry.
>
> Yes ... it uses the "right" package (and the metaData is extended).
>
> Strange, I expected the XMLHandler to use the "original" package.
>
> Greetings,
>
> Ralf
>
> BTW: The new ePackage is always a superset (as expected) from the
> "original" ePackage (additional classes, attributes, generalizations).
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #542669 is a reply to message #542631] |
Fri, 25 June 2010 14:50 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
Comments below.
Ralf Buschermoehle wrote:
> Hi,
>
> Hm, is it possible at all to load a model based on a dynamically
> created EPackage?
Of course. We have several articles about this.
>
> Since then all (pre/post/...)Load Operations should use dynamic Object
> access (eGet, eSet).
The serialization and deserialization code is purely reflective so
dynamic verses generated is irrelevant.
>
> Greetings,
>
> Ralf
>
> On 25.06.2010 10:31, Ralf Buschermoehle wrote:
>> Hi Ed,
>>
>> On 24.06.2010 21:46, Ed Merks wrote:
>>
>>>> How it is possible to "convince" the ...
>>>>
>>>> Resource resource =
>>>> reflectivStateChart.resourceManagement.resourceSet.createRes ource(fileURI);
>>>>
>>>>
>>>>
>>>> resource.load(options);
>>>>
>>>> ... action to use the assigned EPackage?
>>> Have a look at what XMLHandler.getPackageForURI is up to. I'd expect it
>>> to be using the resource set's package registry.
>>
>> Yes ... it uses the "right" package (and the metaData is extended).
>>
>> Strange, I expected the XMLHandler to use the "original" package.
>>
>> Greetings,
>>
>> Ralf
>>
>> BTW: The new ePackage is always a superset (as expected) from the
>> "original" ePackage (additional classes, attributes, generalizations).
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #542710 is a reply to message #542669] |
Fri, 25 June 2010 16:33 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi Ed,
comments below. Thanks for the fast replies ... as always. :)
On 25.06.2010 16:50, Ed Merks wrote:
>> Hm, is it possible at all to load a model based on a dynamically
>> created EPackage?
> Of course. We have several articles about this.
Ah ok, do you have some hints where to find them? I would like to
extract some of our code for a small example.
>> Since then all (pre/post/...)Load Operations should use dynamic Object
>> access (eGet, eSet).
> The serialization and deserialization code is purely reflective so
> dynamic verses generated is irrelevant.
Maybe I checked the wrong code snipped. I debugged the
XMLHandler.getPackageForURI() and this package was the right/modified
one. Anywhere else where I should look?
Is there any possiblity that
reflectivStateChart.resourceManagement.resourceSet.getPackag eRegistry().getEPackage(...)
with the nsURI of the loaded EObject is different from the one that has
been used during the load to create the EObject?
Greetings,
Ralf
>>>>> Resource resource =
>>>>> reflectivStateChart.resourceManagement.resourceSet.createRes ource(fileURI);
>>>>>
>>>>>
>>>>>
>>>>> resource.load(options);
>>>>>
>>>>> ... action to use the assigned EPackage?
>>>> Have a look at what XMLHandler.getPackageForURI is up to. I'd expect it
>>>> to be using the resource set's package registry.
>>>
>>> Yes ... it uses the "right" package (and the metaData is extended).
>>>
>>> Strange, I expected the XMLHandler to use the "original" package.
>>>
>>> Greetings,
>>>
>>> Ralf
>>>
>>> BTW: The new ePackage is always a superset (as expected) from the
>>> "original" ePackage (additional classes, attributes, generalizations).
>>
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #542720 is a reply to message #542710] |
Fri, 25 June 2010 17:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030509000205040004070300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ralf,
There's this one on EMF's documentation page:
Build metamodels with dynamic EMF
< http://www.ibm.com/developerworks/library/os-eclipse-dynamic emf/>
If you right click on an EClass, you can invoke Create Dynamic
Instance... and that will demonstrate dynamic EMF in action.
You could set a breakpoint in your generated class' constructor to see
why that would be getting used. Normally the deserializer finds the
package using the method you check, gets the EClass from that package,
and uses the package's factory to create an instance. So if that
package is dynamic, you should end up with a dynamic instance.
Ralf Buschermoehle wrote:
> Hi Ed,
>
> comments below. Thanks for the fast replies ... as always. :)
>
> On 25.06.2010 16:50, Ed Merks wrote:
>
>>> Hm, is it possible at all to load a model based on a dynamically
>>> created EPackage?
>> Of course. We have several articles about this.
>
> Ah ok, do you have some hints where to find them? I would like to
> extract some of our code for a small example.
>
>>> Since then all (pre/post/...)Load Operations should use dynamic Object
>>> access (eGet, eSet).
>> The serialization and deserialization code is purely reflective so
>> dynamic verses generated is irrelevant.
>
> Maybe I checked the wrong code snipped. I debugged the
> XMLHandler.getPackageForURI() and this package was the right/modified
> one. Anywhere else where I should look?
>
> Is there any possiblity that
> reflectivStateChart.resourceManagement.resourceSet.getPackag eRegistry().getEPackage(...)
>
> with the nsURI of the loaded EObject is different from the one that
> has been used during the load to create the EObject?
>
> Greetings,
>
> Ralf
>
>>>>>> Resource resource =
>>>>>> reflectivStateChart.resourceManagement.resourceSet.createRes ource(fileURI);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> resource.load(options);
>>>>>>
>>>>>> ... action to use the assigned EPackage?
>>>>> Have a look at what XMLHandler.getPackageForURI is up to. I'd
>>>>> expect it
>>>>> to be using the resource set's package registry.
>>>>
>>>> Yes ... it uses the "right" package (and the metaData is extended).
>>>>
>>>> Strange, I expected the XMLHandler to use the "original" package.
>>>>
>>>> Greetings,
>>>>
>>>> Ralf
>>>>
>>>> BTW: The new ePackage is always a superset (as expected) from the
>>>> "original" ePackage (additional classes, attributes, generalizations).
>>>
>
--------------030509000205040004070300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ralf,<br>
<br>
There's this one on EMF's documentation page:<br>
<blockquote><a target="_dw"
href=" http://www.ibm.com/developerworks/library/os-eclipse-dynamic emf/">Build
metamodels with dynamic EMF</a><br>
</blockquote>
If you right click on an EClass, you can invoke Create Dynamic
Instance... and that will demonstrate dynamic EMF in action.<br>
<br>
You could set a breakpoint in your generated class' constructor to see
why that would be getting used. Normally the deserializer finds the
package using the method you check, gets the EClass from that package,
and uses the package's factory to create an instance. So if that
package is dynamic, you should end up with a dynamic instance.<br>
<br>
<br>
Ralf Buschermoehle wrote:
<blockquote cite="mid:i02loi$93u$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
<br>
comments below. Thanks for the fast replies ... as always. :)
<br>
<br>
On 25.06.2010 16:50, Ed Merks wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Hm, is it possible at all to load a model
based on a dynamically
<br>
created EPackage?
<br>
</blockquote>
Of course. We have several articles about this.
<br>
</blockquote>
<br>
Ah ok, do you have some hints where to find them? I would like to
extract some of our code for a small example.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Since then all (pre/post/...)Load
Operations should use dynamic Object
<br>
access (eGet, eSet).
<br>
</blockquote>
The serialization and deserialization code is purely reflective so
<br>
dynamic verses generated is irrelevant.
<br>
</blockquote>
<br>
Maybe I checked the wrong code snipped. I debugged the
XMLHandler.getPackageForURI() and this package was the right/modified
one. Anywhere else where I should look?
<br>
<br>
Is there any possiblity that
<br>
reflectivStateChart.resourceManagement.resourceSet.getPackag eRegistry().getEPackage(...)
<br>
with the nsURI of the loaded EObject is different from the one that has
been used during the load to create the EObject?
<br>
<br>
Greetings,
<br>
<br>
Ralf
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Resource resource =
<br>
reflectivStateChart.resourceManagement.resourceSet.createRes ource(fileURI);
<br>
<br>
<br>
<br>
resource.load(options);
<br>
<br>
.... action to use the assigned EPackage?
<br>
</blockquote>
Have a look at what XMLHandler.getPackageForURI is up to. I'd expect it
<br>
to be using the resource set's package registry.
<br>
</blockquote>
<br>
Yes ... it uses the "right" package (and the metaData is extended).
<br>
<br>
Strange, I expected the XMLHandler to use the "original" package.
<br>
<br>
Greetings,
<br>
<br>
Ralf
<br>
<br>
BTW: The new ePackage is always a superset (as expected) from the
<br>
"original" ePackage (additional classes, attributes, generalizations).
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------030509000205040004070300--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #542741 is a reply to message #542720] |
Fri, 25 June 2010 18:24 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi Ed,
comments inline. I quit stop saying thank you ...
On 25.06.2010 19:15, Ed Merks wrote:
> If you right click on an EClass, you can invoke Create Dynamic
> Instance... and that will demonstrate dynamic EMF in action.
>
> You could set a breakpoint in your generated class' constructor to see
> why that would be getting used. Normally the deserializer finds the
> package using the method you check, gets the EClass from that package,
> and uses the package's factory to create an instance. So if that package
> is dynamic, you should end up with a dynamic instance.
I don't know why I did not see this before :) ... well ... it seems to
be a problem that we have some "static" EObject creations (among our
"dynamic" ones) \forall loaded objects.
The Package is the same ... but the FactoryImpl uses the static
createObjectX methods. As default we added a dynamic creation.
public EObject create(EClass eClass) {
switch (eClass.getClassifierID()) {
...
default:
return super.create(eClass);
But this is only applied during object loading when the classifierID is
unknown (so never for all loaded objects). Thus we have the same package
for all objects, but since the dynamic objects have a different
generalization hierarchy we have some problems.
I tried to change everything in the object creation to dynamic (simply
by moving "super.create(eClass)" up, but then some validation fails:
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value
'org.eclipse.emf.ecore.impl.DynamicEObjectImpl@3e5a4b27 (eClass:
org.eclipse.emf.ecore.impl.EClassImpl@4feb0640 (name: MethodPlugin)
(instanceClassName: null) (abstract: false, interface: false))' is not
legal. (file: ...)at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
Any chance to avoid this?
A second thought was to set the EClass to the same EClass of all loaded
objects with ((EObjectImpl)eObject).eSetClass(eObject.eClass()); and
this "make" it dynamic.
But then I ran into an error when I try to get a reference with type
BasicEStoreList<?> - simply when I access it which is kind of akward
since other non collection types just work fine. When I try to debug the
code I can't even look into into the "object"
"com.sun.jdi.InvocationException occurred invoking method."
after I "object = eObject.eGet(eStructuralFeature);" got it. Is there a
problem when "re-dynamic" objects that have attributes that are collections?
Greetings,
Ralf
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #542748 is a reply to message #542741] |
Fri, 25 June 2010 19:19 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
Comments below.
Ralf Buschermoehle wrote:
> Hi Ed,
>
> comments inline. I quit stop saying thank you ...
>
> On 25.06.2010 19:15, Ed Merks wrote:
>
>> If you right click on an EClass, you can invoke Create Dynamic
>> Instance... and that will demonstrate dynamic EMF in action.
>>
>> You could set a breakpoint in your generated class' constructor to see
>> why that would be getting used. Normally the deserializer finds the
>> package using the method you check, gets the EClass from that package,
>> and uses the package's factory to create an instance. So if that package
>> is dynamic, you should end up with a dynamic instance.
>
> I don't know why I did not see this before :) ... well ... it seems to
> be a problem that we have some "static" EObject creations (among our
> "dynamic" ones) \forall loaded objects.
>
> The Package is the same ... but the FactoryImpl uses the static
> createObjectX methods. As default we added a dynamic creation.
>
> public EObject create(EClass eClass) {
> switch (eClass.getClassifierID()) {
> ...
> default:
> return super.create(eClass);
>
> But this is only applied during object loading when the classifierID
> is unknown (so never for all loaded objects). Thus we have the same
> package for all objects, but since the dynamic objects have a
> different generalization hierarchy we have some problems.
>
> I tried to change everything in the object creation to dynamic (simply
> by moving "super.create(eClass)" up, but then some validation fails:
>
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value
> 'org.eclipse.emf.ecore.impl.DynamicEObjectImpl@3e5a4b27 (eClass:
> org.eclipse.emf.ecore.impl.EClassImpl@4feb0640 (name: MethodPlugin)
> (instanceClassName: null) (abstract: false, interface: false))' is not
> legal. (file: ...)at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
>
> Any chance to avoid this?
I'm not sure I understand this mixing of static and dynamic.
>
>
>
> A second thought was to set the EClass to the same EClass of all
> loaded objects with
> ((EObjectImpl)eObject).eSetClass(eObject.eClass()); and this "make" it
> dynamic.
No, that's not likely to work.
>
> But then I ran into an error when I try to get a reference with type
> BasicEStoreList<?> - simply when I access it which is kind of akward
> since other non collection types just work fine. When I try to debug
> the code I can't even look into into the "object"
>
> "com.sun.jdi.InvocationException occurred invoking method."
>
> after I "object = eObject.eGet(eStructuralFeature);" got it. Is there
> a problem when "re-dynamic" objects that have attributes that are
> collections?
Not a general one no. But if you're mixing static and dynamic and there
are versions of both, you can't exchange them; the dynamic instances to
implement the generated interfaces.
I think I need to understand this mixing of static and dynamic for the
same package. That sounds odd and in many cases just isn't going to
work ever.
>
> Greetings,
>
> Ralf
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #543377 is a reply to message #543196] |
Tue, 29 June 2010 08:42 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi Ed,
as far as I understood I can tweak the NSURIs in the model (before
loading) pointing to the dynamic package (with a new NSURI) e.g.,
"xmlns:uma="http://www.eclipse.org/epf/uma/1.0.5" to
"xmlns:uma="http://www.eclipse.org/epf/uma/1.0.5-my-new-version".
But what do you have in mind regarding the mentioned URI mapping?
I checked the class "URIMappingRegistryImpl" but this refers only to
file URIs, right not nsURIs in a file?
Greetings,
Ralf
On 28.06.2010 18:27, Ed Merks wrote:
> Ralf,
>
> I explained how. :-P
>
> I'm not sure how you build the dynamic instance. Did you create it
> programmatically or load it from a resource. Assuming the latter, you'd
> could either tweak the serialization or use a URI mapping to redirect
> references to the loaded base model to use registered generated model
>
> Cheers,
> Ed
>
>
> Ralf Buschermoehle wrote:
>> Hi Ed,
>>
>> On 28.06.2010 18:01, Ed Merks wrote:
>>> You could make your dynamic model reference the static generated model;
>>> the references in the serialization would use the nsURI of the package
>>> rather than the physical location of the serialized version of it.
>>
>> How?
>>
>>
>>
>> I just checked and to be correct ... (solution b simply creates an
>> object in between)
>>
>> System.out.println("A - SuperClasses : " + ((EClass)
>> eObject.eClass().getEPackage().getEClassifier("ClassX")).getEAllSuperTypes());
>>
>> // static on eObject itself
>> System.out.println("B - SuperClasses : " +
>> eObject.eClass().getEPackage().getEFactoryInstance().create( (EClass)
>> eObject.eClass().getEPackage().getEClassifier("ClassX")).eClass().getEAllSuperTypes());
>>
>>
>> Greetings,
>>
>> Ralf
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #543475 is a reply to message #543377] |
Tue, 29 June 2010 14:26 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
You'd use the resource set's URI map to redirect the physical location
URI to the nsURI so that getResource, which also consults the package
registry, finds the generated registered package rather than loading a
dynamic version of it.
Ralf Buschermoehle wrote:
> Hi Ed,
>
> as far as I understood I can tweak the NSURIs in the model (before
> loading) pointing to the dynamic package (with a new NSURI) e.g.,
> "xmlns:uma="http://www.eclipse.org/epf/uma/1.0.5" to
> "xmlns:uma="http://www.eclipse.org/epf/uma/1.0.5-my-new-version".
>
>
> But what do you have in mind regarding the mentioned URI mapping?
>
> I checked the class "URIMappingRegistryImpl" but this refers only to
> file URIs, right not nsURIs in a file?
>
> Greetings,
>
> Ralf
>
> On 28.06.2010 18:27, Ed Merks wrote:
>> Ralf,
>>
>> I explained how. :-P
>>
>> I'm not sure how you build the dynamic instance. Did you create it
>> programmatically or load it from a resource. Assuming the latter, you'd
>> could either tweak the serialization or use a URI mapping to redirect
>> references to the loaded base model to use registered generated model
>>
>> Cheers,
>> Ed
>>
>>
>> Ralf Buschermoehle wrote:
>>> Hi Ed,
>>>
>>> On 28.06.2010 18:01, Ed Merks wrote:
>>>> You could make your dynamic model reference the static generated
>>>> model;
>>>> the references in the serialization would use the nsURI of the package
>>>> rather than the physical location of the serialized version of it.
>>>
>>> How?
>>>
>>>
>>>
>>> I just checked and to be correct ... (solution b simply creates an
>>> object in between)
>>>
>>> System.out.println("A - SuperClasses : " + ((EClass)
>>> eObject.eClass().getEPackage().getEClassifier("ClassX")).getEAllSuperTypes());
>>>
>>>
>>> // static on eObject itself
>>> System.out.println("B - SuperClasses : " +
>>> eObject.eClass().getEPackage().getEFactoryInstance().create( (EClass)
>>> eObject.eClass().getEPackage().getEClassifier("ClassX")).eClass().getEAllSuperTypes());
>>>
>>>
>>>
>>> Greetings,
>>>
>>> Ralf
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #544666 is a reply to message #543475] |
Mon, 05 July 2010 08:22 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi Ed,
first of all the tweaking of the nsURIs in the model files works ...
only some XMI models seem to use an XML Handler ...
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
reference '118cba5'.
(file:/dv/ws/runtime-rmof-configuration/BenchmarkModels2/RMO FL2-temp1.rmof,
6, 100)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
So that general="#118cba5" in the model file is not resolved for <clazz
ObjectID="118cba5". Which is a little strange, because XMI is registered
for all files ...
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XMIResourceFactoryImpl());
On 29.06.2010 16:26, Ed Merks wrote:
> You'd use the resource set's URI map to redirect the physical location
> URI to the nsURI so that getResource, which also consults the package
> registry, finds the generated registered package rather than loading a
> dynamic version of it.
So getResource can also map "file_A, nsURI_A to nsURI_B" ?
Greetings,
Ralf
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #544713 is a reply to message #544666] |
Mon, 05 July 2010 10:26 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hm, I changed the registry so that the XMI Handler is used ... but still
.... the references are not resolved in the dynamic version. The static
version can load models (which are not based on the extended/dynamic
package - of course).
I also used some additional options i found in the generated code
options.put(XMIResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
options.put(XMIResource.OPTION_USE_ENCODED_ATTRIBUTE_STYLE,B oolean.TRUE);
options.put(XMIResource.OPTION_USE_LEXICAL_HANDLER, Boolean.TRUE);
But no(?) effect - at least regarding the XMI references.
Greetings,
Ralf
On 05.07.2010 10:22, Ralf Buschermoehle wrote:
> Hi Ed,
>
> first of all the tweaking of the nsURIs in the model files works ...
> only some XMI models seem to use an XML Handler ...
>
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
> reference '118cba5'.
> (file:/dv/ws/runtime-rmof-configuration/BenchmarkModels2/RMO FL2-temp1.rmof,
> 6, 100)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
>
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
>
>
> So that general="#118cba5" in the model file is not resolved for <clazz
> ObjectID="118cba5". Which is a little strange, because XMI is registered
> for all files ...
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
> new XMIResourceFactoryImpl());
>
>
>
> On 29.06.2010 16:26, Ed Merks wrote:
>
>> You'd use the resource set's URI map to redirect the physical location
>> URI to the nsURI so that getResource, which also consults the package
>> registry, finds the generated registered package rather than loading a
>> dynamic version of it.
>
> So getResource can also map "file_A, nsURI_A to nsURI_B" ?
>
> Greetings,
>
> Ralf
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #544775 is a reply to message #544666] |
Mon, 05 July 2010 13:24 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
XMLHandler is the base class that's used with all XML-based
serializations. I'm not sure how that relates to a problem with a
reference not resolving. Probably this code in XMLHandler is kicking in:
else if (isEndDocument)
{
error
(new UnresolvedReferenceException
((String) ref.getValue(),
getLocation(),
ref.getLineNumber(),
ref.getColumnNumber()));
}
so try to figure out why the reference isn't being found in
handleForwardReferences.
Ralf Buschermoehle wrote:
> Hi Ed,
>
> first of all the tweaking of the nsURIs in the model files works ...
> only some XMI models seem to use an XML Handler ...
>
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
> reference '118cba5'.
> (file:/dv/ws/runtime-rmof-configuration/BenchmarkModels2/RMO FL2-temp1.rmof,
> 6, 100)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
>
>
> So that general="#118cba5" in the model file is not resolved for
> <clazz ObjectID="118cba5". Which is a little strange, because XMI is
> registered for all files ...
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
> new XMIResourceFactoryImpl());
>
>
>
> On 29.06.2010 16:26, Ed Merks wrote:
>
>> You'd use the resource set's URI map to redirect the physical location
>> URI to the nsURI so that getResource, which also consults the package
>> registry, finds the generated registered package rather than loading a
>> dynamic version of it.
>
> So getResource can also map "file_A, nsURI_A to nsURI_B" ?
>
> Greetings,
>
> Ralf
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #544826 is a reply to message #544775] |
Mon, 05 July 2010 15:35 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi Ed,
all references are correct in the file/model.
The problem is that the XMLHandler seems to try to parse XMLPath
references instead of XMI references ... and I don't know why because
org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used to parse
resources every time (according to several debug sessions).
Greetings,
Ralf
On 05.07.2010 15:24, Ed Merks wrote:
> Ralf,
>
> XMLHandler is the base class that's used with all XML-based
> serializations. I'm not sure how that relates to a problem with a
> reference not resolving. Probably this code in XMLHandler is kicking in:
>
> else if (isEndDocument)
> {
> error
> (new UnresolvedReferenceException
> ((String) ref.getValue(),
> getLocation(),
> ref.getLineNumber(),
> ref.getColumnNumber()));
> }
>
> so try to figure out why the reference isn't being found in
> handleForwardReferences.
>
>
> Ralf Buschermoehle wrote:
>> Hi Ed,
>>
>> first of all the tweaking of the nsURIs in the model files works ...
>> only some XMI models seem to use an XML Handler ...
>>
>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
>> reference '118cba5'.
>> (file:/dv/ws/runtime-rmof-configuration/BenchmarkModels2/RMO FL2-temp1.rmof,
>> 6, 100)
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
>>
>> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
>>
>>
>> So that general="#118cba5" in the model file is not resolved for
>> <clazz ObjectID="118cba5". Which is a little strange, because XMI is
>> registered for all files ...
>>
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
>> new XMIResourceFactoryImpl());
>>
>>
>>
>> On 29.06.2010 16:26, Ed Merks wrote:
>>
>>> You'd use the resource set's URI map to redirect the physical location
>>> URI to the nsURI so that getResource, which also consults the package
>>> registry, finds the generated registered package rather than loading a
>>> dynamic version of it.
>>
>> So getResource can also map "file_A, nsURI_A to nsURI_B" ?
>>
>> Greetings,
>>
>> Ralf
|
|
|
| Re: ResourceSet uses default EPackage instead of created/assigned EPackage during resource.load() [message #544827 is a reply to message #544826] |
Mon, 05 July 2010 16:03 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
It should end up calling Resource.getEObject with the string. If that
string doesn't start with a /, it should look that thing up as an ID.
Ralf Buschermoehle wrote:
> Hi Ed,
>
> all references are correct in the file/model.
>
> The problem is that the XMLHandler seems to try to parse XMLPath
> references instead of XMI references ... and I don't know why because
> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used to parse
> resources every time (according to several debug sessions).
>
> Greetings,
>
> Ralf
>
> On 05.07.2010 15:24, Ed Merks wrote:
>> Ralf,
>>
>> XMLHandler is the base class that's used with all XML-based
>> serializations. I'm not sure how that relates to a problem with a
>> reference not resolving. Probably this code in XMLHandler is kicking in:
>>
>> else if (isEndDocument)
>> {
>> error
>> (new UnresolvedReferenceException
>> ((String) ref.getValue(),
>> getLocation(),
>> ref.getLineNumber(),
>> ref.getColumnNumber()));
>> }
>>
>> so try to figure out why the reference isn't being found in
>> handleForwardReferences.
>>
>>
>> Ralf Buschermoehle wrote:
>>> Hi Ed,
>>>
>>> first of all the tweaking of the nsURIs in the model files works ...
>>> only some XMI models seem to use an XML Handler ...
>>>
>>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
>>> reference '118cba5'.
>>> (file:/dv/ws/runtime-rmof-configuration/BenchmarkModels2/RMO FL2-temp1.rmof,
>>>
>>> 6, 100)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:83)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:191)
>>> at
>>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
>>>
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
>>>
>>>
>>>
>>> So that general="#118cba5" in the model file is not resolved for
>>> <clazz ObjectID="118cba5". Which is a little strange, because XMI is
>>> registered for all files ...
>>>
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put(Resource.Factory.Registry.DEFAULT_EXTENSION,
>>>
>>> new XMIResourceFactoryImpl());
>>>
>>>
>>>
>>> On 29.06.2010 16:26, Ed Merks wrote:
>>>
>>>> You'd use the resource set's URI map to redirect the physical location
>>>> URI to the nsURI so that getResource, which also consults the package
>>>> registry, finds the generated registered package rather than loading a
>>>> dynamic version of it.
>>>
>>> So getResource can also map "file_A, nsURI_A to nsURI_B" ?
>>>
>>> Greetings,
>>>
>>> Ralf
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 12:55:32 GMT 2024
Powered by FUDForum. Page generated in 0.04675 seconds |
] 
Search
Help
Register
Login
Home
