| unresolving crossreferencer ... still resolves [message #427366] |
Fri, 13 February 2009 23:26  |
|
This is a multi-part message in MIME format.
--------------000803050402030908000508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I have two ecore models say model1 and model2. model1 has an EClass c1,
model2 has an EClass c2 with its supertype set to model1/c1.
With such a setup, if I try something like
ResourceSet rs = new ResourceSetImpl();
Resource model2 = rs.getResource(model2URI, true);
CrossReferencer referencer = new CrossReferencer(rs) {
{
crossReference();
}
@Override
protected boolean resolve() {
return false;
}
};
resourceSet.getResources().size() <= returns 2 and actually contains
model1 where I only asked for model2.
I don't know if the behavior is the same when the link from a model to
another is anywhere else than the "eSuperTypes" reference (the actual
culprit is "eAllAttributes" which is retrieved somehow from the
crossReferencer and simply ignores the "resolve()" method), but this is
obviously not the behavior I expected :).
Is there any way to visit all references of a given model without
resolving the proxies other than the crossreferencer?
Laurent Goubet
Obeo
--------------000803050402030908000508
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr/">Obeo</a>
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard
--------------000803050402030908000508--
|
|
|
| Re: unresolving crossreferencer ... still resolves [message #427367 is a reply to message #427366] |
Sat, 14 February 2009 12:36  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Laurent,
Comments below.
laurent Goubet wrote:
> Hi,
>
> I have two ecore models say model1 and model2. model1 has an EClass
> c1, model2 has an EClass c2 with its supertype set to model1/c1.
>
> With such a setup, if I try something like
>
> ResourceSet rs = new ResourceSetImpl();
> Resource model2 = rs.getResource(model2URI, true);
> CrossReferencer referencer = new CrossReferencer(rs) {
> {
> crossReference();
> }
>
> @Override
> protected boolean resolve() {
> return false;
> }
> };
> resourceSet.getResources().size() <= returns 2 and actually contains
> model1 where I only asked for model2.
>
> I don't know if the behavior is the same when the link from a model to
> another is anywhere else than the "eSuperTypes" reference (the actual
> culprit is "eAllAttributes" which is retrieved somehow from the
> crossReferencer and simply ignores the "resolve()" method), but this
> is obviously not the behavior I expected :).
There are features in the Ecore model such as getEAllSuperTypes which
are derived and to be computed properly must resolve proxies. I.e., we
need to walk all the eSuperTypes, their eSuperTypes, and so on. I can't
see any way to avoid such a thing.
>
> Is there any way to visit all references of a given model without
> resolving the proxies other than the crossreferencer?
Yes, but if you visit a derived feature that resolves proxies in order
to compute the derivation, you'll have the same problem. If you remove
model2 from the resource set, all proxies will fail to resolve, so
that's a brute force way of achieving your goal.
>
> Laurent Goubet
> Obeo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: unresolving crossreferencer ... still resolves [message #427369 is a reply to message #427367] |
Sat, 14 February 2009 13:56 |
|
This is a multi-part message in MIME format.
--------------060006080906090709090701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Ed,
Well the problem is, in my case, the proxy cannot be resolved properly :
model1 has been moved and the proxyURI is wrong. What I am trying to
achieve through the cross referencer is to check whether the
crossReferencedObject is a proxy or not, then properly restore the link.
Yet since eAllSuperType tries to resolve this itself, I have a "dummy"
resource created in my resourceSet with the old URI of model1 ... and
absolutely no content whatsoever. The only workaround I found for now is
to iterate over the resourceSet's resources afterwards, check if any of
them has its content list's size equal to 0, and forcely remove those
from the resourceSet. That will not work, however, if a resource with
the old URI still exists : both the old resource and the new (towards
which I made all references point) will be loaded in the resourceSet and
I will have no way to remove the old resources since they will have
content in this case.
I might have missed something in the framework that would have allowed
me to resolve proxies without the use of a crossReferencer, but that's
all I found to achieve this goal. Does this seem like the right approach
to you? And is there any way I could bypass the derived feature
resolution? Maybe by having the crossReferencer ignore derived features?
Laurent Goubet
Obeo
Ed Merks a
|
|
|
| Re: unresolving crossreferencer ... still resolves [message #427371 is a reply to message #427369] |
Sat, 14 February 2009 17:57 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060206080009080606000104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Laurent,
Comments below.
laurent Goubet wrote:
> Hi Ed,
>
> Well the problem is, in my case, the proxy cannot be resolved properly
> : model1 has been moved and the proxyURI is wrong. What I am trying to
> achieve through the cross referencer is to check whether the
> crossReferencedObject is a proxy or not, then properly restore the link.
Could you use UnresolvedProxyCrossReferencer?
>
> Yet since eAllSuperType tries to resolve this itself, I have a "dummy"
> resource created in my resourceSet with the old URI of model1 ... and
> absolutely no content whatsoever. The only workaround I found for now
> is to iterate over the resourceSet's resources afterwards, check if
> any of them has its content list's size equal to 0, and forcely remove
> those from the resourceSet.
You can check their getErrors too... And given that you seem to know
which broken link your repairing, won't you know exactly which resource
to clean up?
> That will not work, however, if a resource with the old URI still
> exists : both the old resource and the new (towards which I made all
> references point) will be loaded in the resourceSet and I will have no
> way to remove the old resources since they will have content in this
> case.
It's important that it be removed?
>
> I might have missed something in the framework that would have allowed
> me to resolve proxies without the use of a crossReferencer, but that's
> all I found to achieve this goal. Does this seem like the right
> approach to you? And is there any way I could bypass the derived
> feature resolution?
You could specialize
protected EContentsEList.FeatureIterator<EObject>
getCrossReferences(EObject eObject)
{
return
(EContentsEList.FeatureIterator<EObject>)
(resolve() ?
eObject.eCrossReferences().iterator() :
((InternalEList<EObject>)eObject.eCrossReferences()).basicIterator());
}
So that rather than iterate over all cross reference, you create an
ECrossReferenceList that excludes derived features. Maybe that would be
useful in the framework...
> Maybe by having the crossReferencer ignore derived features?
Yes, but it's important not even to visit them at all...
>
> Laurent Goubet
> Obeo
>
> Ed Merks a
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: unresolving crossreferencer ... still resolves [message #427379 is a reply to message #427371] |
Mon, 16 February 2009 11:45 |
|
This is a multi-part message in MIME format.
--------------090404070501030505060806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Ed,
Thanks, that's a lot of information to digest :). I'll try and see if
one of these suggestions answers my needs and come back to you with any
update ;).
Laurent Goubet
Obeo
Ed Merks a
|
|
|
Powered by
FUDForum. Page generated in 0.03109 seconds
] 
Search
Help
Register
Login
Home
