Home » Modeling » EMF » [EMF] Wrong URI for proxy of controlled resource
| [EMF] Wrong URI for proxy of controlled resource [message #1587866] |
Tue, 27 January 2015 16:04  |
|
Hello,
I'm currently working on Sirius bugzilla 458151 [1].
During the analysis, I think I discovered a bug in EMF.
Use case:
* A resource B.ecore with a package RootB.
* RootB contains a package b1 that is controlled in another B1.ecore
resource.
* b1 contains a package b2. And b2 contains a class ClassB.
Steps to reproduce:
* Unload B1 and call EcoreUtil.getURI(eClassB);
* The URI is something like "file:/myPath/B1.ecore#//b2.1/ClassB".
* I think it should have the same value as before the unload
"file:/myPath/B1.ecore#//b2/ClassB".
I create a simple Junit to reveal the problem [2].
My analysis:
During the unload, the ProxyURI is set on all EObject of B1.ecore.
For computation of URI fragment of ClassB, I think that there is a
problem in EModelElementImpl.eURIFragmentSegment(EStructuralFeature,
EObject), corresponding stack is here [3].
The eObject parameter is the parent proxy b2 (with a eProxyURI =
"file:/myPath/B1.ecore#//b2").
The method eContents() returns another instance, not a proxy,
corresponding to this package, because the eContents() resolves the
proxy. The resolution is done because we are in a
ResolvingFeatureIteratorImpl. So just after the test "if (otherEObject
== eObject)" return false because eObject is a proxy of b2 and
otherEObject is b2.
Perforce, name.equals(otherENamedElement.getName() and the ". + count"
is added to the name.
Is it a bug or not?
Perhaps a test like
if (container.eIsProxy())
should be added in method
org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragment(EObject)
and in this case consider
container.eProxyURI().fragment()
Thank you for your help!
Best regards,
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=458151
[2] https://bugs.eclipse.org/bugs/attachment.cgi?id=250268
[3] Corresponding stack
EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature,
EObject) line: 334
EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject) line: 670
EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject)
line: 548
EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject) line:
1574
EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1635
EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 631
EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1650
EMFUnloadWithStrangeProxyURITests.init(boolean) line: 113
EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment() line: 50
--
Laurent - Obeo
Laurent Redor - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: [EMF] Wrong URI for proxy of controlled resource [message #1591087 is a reply to message #1587866] |
Thu, 29 January 2015 10:02  |
|
here is a copy of exchanges with Ed (his first answer was in private by
mistake).
>
> Hi,
>
> I continue to investigate.
>
> By adapting the JUnit test, I observed that the behavior is different if B1.ecore is a fragment of B.ecore or if B1.ecore is a "standalone" resource.
>
> In case of B1.ecore as "standalone" resource, the behavior is OK. But if B1.ecore is a fragment, there is the mentioned bug.
>
> The difference is in BasicEObjectImpl.eInternalResource(). In case of "standalone" resource, no resource is returned. And so the proxy is not resolved. And so, the initial problematic test "if (otherEObject
> == eObject)" return true. But in case of fragment, the "parent" resource is returned, B.ecore, in our case. And this is sufficient to resolve the proxy and then have the problem.
>
> Is it expected to have such a different behavior?
>
> The corresponding calling stack in both case:
> EPackageImpl(BasicEObjectImpl).eInternalResource() line: 939
> EPackageImpl(BasicEObjectImpl).eResource() line: 920
> EcoreUtil.resolve(EObject, EObject) line: 258
> EPackageImpl(BasicEObjectImpl).eResolveProxy(InternalEObject) line: 1473
> EObjectContainmentWithInverseEList$Resolving<E>(EcoreEList<E>).resolveProxy(EObject) line: 206
> EObjectContainmentWithInverseEList$Resolving<E>(EcoreEList<E>).resolve(int, EObject) line: 161
> EObjectContainmentWithInverseEList$Resolving<E>.resolve(int, E) line: 105
> EObjectContainmentWithInverseEList$Resolving<E>(BasicEList<E>).get(int) line: 348
> ENamedElementImpl$1$1(EContentsEList$FeatureIteratorImpl<E>).hasNext() line: 471
> EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature, EObject) line: 332
> EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject) line: 680
> EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject) line: 630
> EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject) line: 1594
> EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1655
> EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 713
> EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1670
> EMFUnloadWithStrangeProxyURITests.init(boolean) line: 114
> EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment() line: 51
>
> Is it deliberate to answer only to me (and not to all on forum)?
>
>
> Le 27/01/2015 19:21, Laurent Redor a écrit :
>> Le 27/01/2015 18:51, Ed Merks a écrit :
>>> Laurent,
>>>
>>> Comments below.
>>>
>>> On 27.01.2015 17:04, Laurent Redor wrote:
>>>> Hello,
>>>>
>>>> I'm currently working on Sirius bugzilla 458151 [1].
>>>> During the analysis, I think I discovered a bug in EMF.
>>>>
>>>> Use case:
>>>> * A resource B.ecore with a package RootB.
>>>> * RootB contains a package b1 that is controlled in another B1.ecore
>>>> resource.
>>> As I always point out, nested packages are syntactic rat poison that are more likely to cause problems than actually make anything nicer...
>> This is not our real use case. I try to reproduce with a simple example.
>>>> * b1 contains a package b2. And b2 contains a class ClassB.
>>>>
>>>> Steps to reproduce:
>>>> * Unload B1 and call EcoreUtil.getURI(eClassB);
>>>> * The URI is something like "file:/myPath/B1.ecore#//b2.1/ClassB".
>>>> * I think it should have the same value as before the unload
>>>> "file:/myPath/B1.ecore#//b2/ClassB".
>>> Is eClassB.eIsProxy() true? If you cast to InternalEObject, is eProxyURI the URI you show? Which version of EMF are you using?
>> Yes. yes. I try with several versions of EMF (including juno 2.8.3.v20130125 and luna 2.10.1.v20140901).
>>>>
>>>> I create a simple Junit to reveal the problem [2].
>>>>
>>>> My analysis:
>>>> During the unload, the ProxyURI is set on all EObject of B1.ecore.
>>>> For computation of URI fragment of ClassB, I think that there is a
>>>> problem in EModelElementImpl.eURIFragmentSegment(EStructuralFeature,
>>>> EObject), corresponding stack is here [3].
>>>> The eObject parameter is the parent proxy b2 (with a eProxyURI =
>>>> "file:/myPath/B1.ecore#//b2").
>>>> The method eContents() returns another instance, not a proxy,
>>>> corresponding to this package, because the eContents() resolves the
>>>> proxy. The resolution is done because we are in a
>>>> ResolvingFeatureIteratorImpl. So just after the test "if (otherEObject
>>>> == eObject)" return false because eObject is a proxy of b2 and
>>>> otherEObject is b2.
>>>> Perforce, name.equals(otherENamedElement.getName() and the ". + count"
>>>> is added to the name.
>>>>
>>>> Is it a bug or not?
>>> It sounds kind of familiar. I wonder if you're using the latest release?
>> I've not tested with the current mars release.
>>>>
>>>> Perhaps a test like
>>>> if (container.eIsProxy())
>>>> should be added in method
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragment(EObject)
>>>> and in this case consider
>>>> container.eProxyURI().fragment()
>>>>
>>>> Thank you for your help!
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=458151
>>>> [2] https://bugs.eclipse.org/bugs/attachment.cgi?id=250268
>>>> [3] Corresponding stack
>>>> EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature,
>>>> EObject) line: 334
>>>> EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject) line: 670
>>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject)
>>>> line: 548
>>>> EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject) line:
>>>> 1574
>>>> EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1635
>>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 631
>>>> EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1650
>>>> EMFUnloadWithStrangeProxyURITests.init(boolean) line: 113
>>>> EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment() line: 50
>>>>
>>>
>>>
>>
>
--
Laurent - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
Laurent Redor - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: [EMF] Wrong URI for proxy of controlled resource [message #1591095 is a reply to message #1591087] |
Thu, 29 January 2015 10:06 |
|
I will create a bugzilla for further analysis and try to propose a fix.
In fact, I think we can adapt the method
org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragment
(EObject) to avoid calling eURIFragmentSegment for containers being
themselves proxy.
Le 29/01/2015 11:02, Laurent Redor a écrit :
> here is a copy of exchanges with Ed (his first answer was in private by
> mistake).
>
>>
>> Hi,
>>
>> I continue to investigate.
>>
>> By adapting the JUnit test, I observed that the behavior is different
>> if B1.ecore is a fragment of B.ecore or if B1.ecore is a "standalone"
>> resource.
>>
>> In case of B1.ecore as "standalone" resource, the behavior is OK. But
>> if B1.ecore is a fragment, there is the mentioned bug.
>>
>> The difference is in BasicEObjectImpl.eInternalResource(). In case of
>> "standalone" resource, no resource is returned. And so the proxy is
>> not resolved. And so, the initial problematic test "if (otherEObject
>> == eObject)" return true. But in case of fragment, the "parent"
>> resource is returned, B.ecore, in our case. And this is sufficient to
>> resolve the proxy and then have the problem.
>>
>> Is it expected to have such a different behavior?
>>
>> The corresponding calling stack in both case:
>> EPackageImpl(BasicEObjectImpl).eInternalResource() line: 939
>> EPackageImpl(BasicEObjectImpl).eResource() line: 920
>> EcoreUtil.resolve(EObject, EObject) line: 258
>> EPackageImpl(BasicEObjectImpl).eResolveProxy(InternalEObject)
>> line: 1473
>> EObjectContainmentWithInverseEList$Resolving<E>(EcoreEList<E>).resolveProxy(EObject)
>> line: 206
>> EObjectContainmentWithInverseEList$Resolving<E>(EcoreEList<E>).resolve(int,
>> EObject) line: 161
>> EObjectContainmentWithInverseEList$Resolving<E>.resolve(int, E) line: 105
>> EObjectContainmentWithInverseEList$Resolving<E>(BasicEList<E>).get(int) line:
>> 348
>> ENamedElementImpl$1$1(EContentsEList$FeatureIteratorImpl<E>).hasNext()
>> line: 471
>> EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature, EObject)
>> line: 332
>> EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject) line:
>> 680
>> EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject)
>> line: 630
>> EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject)
>> line: 1594
>> EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1655
>> EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 713
>> EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1670
>> EMFUnloadWithStrangeProxyURITests.init(boolean) line: 114
>> EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment()
>> line: 51
>>
>> Is it deliberate to answer only to me (and not to all on forum)?
>>
>>
>> Le 27/01/2015 19:21, Laurent Redor a écrit :
>>> Le 27/01/2015 18:51, Ed Merks a écrit :
>>>> Laurent,
>>>>
>>>> Comments below.
>>>>
>>>> On 27.01.2015 17:04, Laurent Redor wrote:
>>>>> Hello,
>>>>>
>>>>> I'm currently working on Sirius bugzilla 458151 [1].
>>>>> During the analysis, I think I discovered a bug in EMF.
>>>>>
>>>>> Use case:
>>>>> * A resource B.ecore with a package RootB.
>>>>> * RootB contains a package b1 that is controlled in another B1.ecore
>>>>> resource.
>>>> As I always point out, nested packages are syntactic rat poison that
>>>> are more likely to cause problems than actually make anything nicer...
>>> This is not our real use case. I try to reproduce with a simple example.
>>>>> * b1 contains a package b2. And b2 contains a class ClassB.
>>>>>
>>>>> Steps to reproduce:
>>>>> * Unload B1 and call EcoreUtil.getURI(eClassB);
>>>>> * The URI is something like "file:/myPath/B1.ecore#//b2.1/ClassB".
>>>>> * I think it should have the same value as before the unload
>>>>> "file:/myPath/B1.ecore#//b2/ClassB".
>>>> Is eClassB.eIsProxy() true? If you cast to InternalEObject, is
>>>> eProxyURI the URI you show? Which version of EMF are you using?
>>> Yes. yes. I try with several versions of EMF (including juno
>>> 2.8.3.v20130125 and luna 2.10.1.v20140901).
>>>>>
>>>>> I create a simple Junit to reveal the problem [2].
>>>>>
>>>>> My analysis:
>>>>> During the unload, the ProxyURI is set on all EObject of B1.ecore.
>>>>> For computation of URI fragment of ClassB, I think that there is a
>>>>> problem in EModelElementImpl.eURIFragmentSegment(EStructuralFeature,
>>>>> EObject), corresponding stack is here [3].
>>>>> The eObject parameter is the parent proxy b2 (with a eProxyURI =
>>>>> "file:/myPath/B1.ecore#//b2").
>>>>> The method eContents() returns another instance, not a proxy,
>>>>> corresponding to this package, because the eContents() resolves the
>>>>> proxy. The resolution is done because we are in a
>>>>> ResolvingFeatureIteratorImpl. So just after the test "if (otherEObject
>>>>> == eObject)" return false because eObject is a proxy of b2 and
>>>>> otherEObject is b2.
>>>>> Perforce, name.equals(otherENamedElement.getName() and the ". + count"
>>>>> is added to the name.
>>>>>
>>>>> Is it a bug or not?
>>>> It sounds kind of familiar. I wonder if you're using the latest
>>>> release?
>>> I've not tested with the current mars release.
>>>>>
>>>>> Perhaps a test like
>>>>> if (container.eIsProxy())
>>>>> should be added in method
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragment(EObject)
>>>>>
>>>>> and in this case consider
>>>>> container.eProxyURI().fragment()
>>>>>
>>>>> Thank you for your help!
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=458151
>>>>> [2] https://bugs.eclipse.org/bugs/attachment.cgi?id=250268
>>>>> [3] Corresponding stack
>>>>> EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature,
>>>>>
>>>>> EObject) line: 334
>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject)
>>>>> line: 670
>>>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject)
>>>>> line: 548
>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject)
>>>>> line:
>>>>> 1574
>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1635
>>>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 631
>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1650
>>>>> EMFUnloadWithStrangeProxyURITests.init(boolean) line: 113
>>>>> EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment()
>>>>> line: 50
>>>>>
>>>>
>>>>
>>>
>>
--
Laurent - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
Laurent Redor - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: [EMF] Wrong URI for proxy of controlled resource [message #1591392 is a reply to message #1591095] |
Thu, 29 January 2015 13:56 |
|
Corresponding bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=458721
Le 29/01/2015 11:06, Laurent Redor a écrit :
> I will create a bugzilla for further analysis and try to propose a fix.
> In fact, I think we can adapt the method
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragment
> (EObject) to avoid calling eURIFragmentSegment for containers being
> themselves proxy.
>
> Le 29/01/2015 11:02, Laurent Redor a écrit :
>> here is a copy of exchanges with Ed (his first answer was in private by
>> mistake).
>>
>>>
>>> Hi,
>>>
>>> I continue to investigate.
>>>
>>> By adapting the JUnit test, I observed that the behavior is different
>>> if B1.ecore is a fragment of B.ecore or if B1.ecore is a "standalone"
>>> resource.
>>>
>>> In case of B1.ecore as "standalone" resource, the behavior is OK. But
>>> if B1.ecore is a fragment, there is the mentioned bug.
>>>
>>> The difference is in BasicEObjectImpl.eInternalResource(). In case of
>>> "standalone" resource, no resource is returned. And so the proxy is
>>> not resolved. And so, the initial problematic test "if (otherEObject
>>> == eObject)" return true. But in case of fragment, the "parent"
>>> resource is returned, B.ecore, in our case. And this is sufficient to
>>> resolve the proxy and then have the problem.
>>>
>>> Is it expected to have such a different behavior?
>>>
>>> The corresponding calling stack in both case:
>>> EPackageImpl(BasicEObjectImpl).eInternalResource() line: 939
>>> EPackageImpl(BasicEObjectImpl).eResource() line: 920
>>> EcoreUtil.resolve(EObject, EObject) line: 258
>>> EPackageImpl(BasicEObjectImpl).eResolveProxy(InternalEObject)
>>> line: 1473
>>> EObjectContainmentWithInverseEList$Resolving<E>(EcoreEList<E>).resolveProxy(EObject)
>>>
>>> line: 206
>>> EObjectContainmentWithInverseEList$Resolving<E>(EcoreEList<E>).resolve(int,
>>>
>>> EObject) line: 161
>>> EObjectContainmentWithInverseEList$Resolving<E>.resolve(int, E) line:
>>> 105
>>> EObjectContainmentWithInverseEList$Resolving<E>(BasicEList<E>).get(int)
>>> line:
>>> 348
>>> ENamedElementImpl$1$1(EContentsEList$FeatureIteratorImpl<E>).hasNext()
>>> line: 471
>>> EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature,
>>> EObject)
>>> line: 332
>>> EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject) line:
>>> 680
>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject)
>>> line: 630
>>> EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject)
>>> line: 1594
>>> EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1655
>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 713
>>> EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1670
>>> EMFUnloadWithStrangeProxyURITests.init(boolean) line: 114
>>> EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment()
>>> line: 51
>>>
>>> Is it deliberate to answer only to me (and not to all on forum)?
>>>
>>>
>>> Le 27/01/2015 19:21, Laurent Redor a écrit :
>>>> Le 27/01/2015 18:51, Ed Merks a écrit :
>>>>> Laurent,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> On 27.01.2015 17:04, Laurent Redor wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'm currently working on Sirius bugzilla 458151 [1].
>>>>>> During the analysis, I think I discovered a bug in EMF.
>>>>>>
>>>>>> Use case:
>>>>>> * A resource B.ecore with a package RootB.
>>>>>> * RootB contains a package b1 that is controlled in another B1.ecore
>>>>>> resource.
>>>>> As I always point out, nested packages are syntactic rat poison that
>>>>> are more likely to cause problems than actually make anything nicer...
>>>> This is not our real use case. I try to reproduce with a simple
>>>> example.
>>>>>> * b1 contains a package b2. And b2 contains a class ClassB.
>>>>>>
>>>>>> Steps to reproduce:
>>>>>> * Unload B1 and call EcoreUtil.getURI(eClassB);
>>>>>> * The URI is something like "file:/myPath/B1.ecore#//b2.1/ClassB".
>>>>>> * I think it should have the same value as before the unload
>>>>>> "file:/myPath/B1.ecore#//b2/ClassB".
>>>>> Is eClassB.eIsProxy() true? If you cast to InternalEObject, is
>>>>> eProxyURI the URI you show? Which version of EMF are you using?
>>>> Yes. yes. I try with several versions of EMF (including juno
>>>> 2.8.3.v20130125 and luna 2.10.1.v20140901).
>>>>>>
>>>>>> I create a simple Junit to reveal the problem [2].
>>>>>>
>>>>>> My analysis:
>>>>>> During the unload, the ProxyURI is set on all EObject of B1.ecore.
>>>>>> For computation of URI fragment of ClassB, I think that there is a
>>>>>> problem in EModelElementImpl.eURIFragmentSegment(EStructuralFeature,
>>>>>> EObject), corresponding stack is here [3].
>>>>>> The eObject parameter is the parent proxy b2 (with a eProxyURI =
>>>>>> "file:/myPath/B1.ecore#//b2").
>>>>>> The method eContents() returns another instance, not a proxy,
>>>>>> corresponding to this package, because the eContents() resolves the
>>>>>> proxy. The resolution is done because we are in a
>>>>>> ResolvingFeatureIteratorImpl. So just after the test "if
>>>>>> (otherEObject
>>>>>> == eObject)" return false because eObject is a proxy of b2 and
>>>>>> otherEObject is b2.
>>>>>> Perforce, name.equals(otherENamedElement.getName() and the ". +
>>>>>> count"
>>>>>> is added to the name.
>>>>>>
>>>>>> Is it a bug or not?
>>>>> It sounds kind of familiar. I wonder if you're using the latest
>>>>> release?
>>>> I've not tested with the current mars release.
>>>>>>
>>>>>> Perhaps a test like
>>>>>> if (container.eIsProxy())
>>>>>> should be added in method
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragment(EObject)
>>>>>>
>>>>>>
>>>>>> and in this case consider
>>>>>> container.eProxyURI().fragment()
>>>>>>
>>>>>> Thank you for your help!
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=458151
>>>>>> [2] https://bugs.eclipse.org/bugs/attachment.cgi?id=250268
>>>>>> [3] Corresponding stack
>>>>>> EPackageImpl(EModelElementImpl).eURIFragmentSegment(EStructuralFeature,
>>>>>>
>>>>>>
>>>>>> EObject) line: 334
>>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).getURIFragment(EObject)
>>>>>> line: 670
>>>>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).getURIFragment(EObject)
>>>>>> line: 548
>>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).unloaded(InternalEObject)
>>>>>> line:
>>>>>> 1574
>>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).doUnload() line: 1635
>>>>>> EcoreResourceFactoryImpl$1(XMLResourceImpl).doUnload() line: 631
>>>>>> EcoreResourceFactoryImpl$1(ResourceImpl).unload() line: 1650
>>>>>> EMFUnloadWithStrangeProxyURITests.init(boolean) line: 113
>>>>>> EMFUnloadWithStrangeProxyURITests.testURIAfterUnloadWithFragment()
>>>>>> line: 50
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
>
--
Laurent - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
Laurent Redor - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
Goto Forum:
Current Time: Tue Apr 16 20:04:18 GMT 2024
Powered by FUDForum. Page generated in 1.72422 seconds |
] 
Search
Help
Register
Login
Home
