Home » Modeling » EMF » Resolving a proxy using EcoreUtil.resolve
| Resolving a proxy using EcoreUtil.resolve [message #380929] |
Thu, 11 December 2003 17:55  |
Eclipse User |
|
|
|
Ed,
I am running into a problem in which I am trying to resolve an eProxy to a
resource that no longer exists. The problem, as I see it, is that the
EcoreUtil.resolve(...):EObject methods end up creating a new empty resource
when the URI of the eProxy is not found. This doesn't seem like a
desirable behavior. EcoreUtil.resolve(...) calls
ResourceSet.getEObject(URI,true) which, for my situation, ends up creating a
new resource for that URI. An exception is then thrown when the
ResourceSetImpl.demandLoad() is called within
ResourceSetImpl.getResource(URI,true) because there is no underlying file
for that URI.
Is there a better way to check for the existence of the underlying file
prior to creating the new resource? Should I be overriding the getEObject
method ?
Thanks in advance.
Dennis
|
|
| |
| Re: Resolving a proxy using EcoreUtil.resolve [message #380967 is a reply to message #380932] |
Mon, 15 December 2003 08:56  |
| Eclipse User |
|
|
|
We're attempting to handle the case when the resource has been moved so that
it effectively has a new URI. (Picture moving or renaming an XMI file in
the Eclipse workbench.) When a model has a reference to the moved resource,
it still may have the old URI; this is where we've been trying to use
EcoreUtil.resolve(...):EObject. We have other ways of finding which XMI
file actually contains the object the proxy is pointing to. This mechanism,
however, is more expensive than the normal mechanism, so we are trying to
use the normal mechanism whenever possible. When that fails, we can use our
more expensive (but also more robust) resolution.
The question is: What is the most effective way to do this? The EMF team
has done an exemplary job at building in extensibility, but unfortunately
that can make it challenging to decide how to extend.
To us, the only place that makes sense is to override the
'ResourceSet.getEObject(URI,boolean)' method to:
1) Call 'ResourceSet.getResource(URI,false)' using the URI without its
fragment. If the result is non-null, then the Resource exists in the
ResourceSet, so try to resolve the fragment portion of the URI. Return
either null if the fragment doesn't resolve, or the EObject from the
resolution of the fragment. If , then continue.
2) The result from 'ResourceSet.getResource(URI,false)' returned null, so
either the underlying resource is available but has not yet been needed (and
no Resource exists for it), or there isn't even an underlying resource
(i.e., the URI is bad). In either case, call
'ResourceSet.getResource(URI,true)' within a try-catch. If there is no
exception, continue with the resolution of the fragment and return either
the resolved EObject or null. If there is an exception, then there is no
underlying resource (is this assumption correct?), so return null.
Thoughts?
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3FD90210.D8C5C873@ca.ibm.com...
> Dennis,
>
> I'm not clear why the behavior is undesirable. A resource can fail to
load for
> many reasons and even failing to open a stream for the resource URI can
happen
> for many reasons. It seems better to create a resource that records the
failure
> and acts as a placeholder so that other proxies into the same resource
will fail
> that much faster. Having a record of all the required resources seems
like such
> a good thing. Are you sure you really need to be doing something to
change
> this?
>
>
> dfuglsang wrote:
>
> > Ed,
> >
> > I am running into a problem in which I am trying to resolve an eProxy to
a
> > resource that no longer exists. The problem, as I see it, is that the
> > EcoreUtil.resolve(...):EObject methods end up creating a new empty
resource
> > when the URI of the eProxy is not found. This doesn't seem like a
> > desirable behavior. EcoreUtil.resolve(...) calls
> > ResourceSet.getEObject(URI,true) which, for my situation, ends up
creating a
> > new resource for that URI. An exception is then thrown when the
> > ResourceSetImpl.demandLoad() is called within
> > ResourceSetImpl.getResource(URI,true) because there is no underlying
file
> > for that URI.
> >
> > Is there a better way to check for the existence of the underlying file
> > prior to creating the new resource? Should I be overriding the
getEObject
> > method ?
> >
> > Thanks in advance.
> >
> > Dennis
>
|
|
|
| Re: Resolving a proxy using EcoreUtil.resolve [message #380968 is a reply to message #380967] |
Mon, 15 December 2003 09:20 |
| Eclipse User |
|
|
|
Randall,
The algorithm you describe below will still demand create a resource in the
failure case. And no matter what you do, the possible reasons for failure of
ResourceSet.getResource is unbounded. The path of least resistance seems to be
to remove the failed resource as part of cleaning up the proxies that reference
it. Once the proxies are gone, the resource can be removed and will never come
back...
Randall Hauch wrote:
> We're attempting to handle the case when the resource has been moved so that
> it effectively has a new URI. (Picture moving or renaming an XMI file in
> the Eclipse workbench.) When a model has a reference to the moved resource,
> it still may have the old URI; this is where we've been trying to use
> EcoreUtil.resolve(...):EObject. We have other ways of finding which XMI
> file actually contains the object the proxy is pointing to. This mechanism,
> however, is more expensive than the normal mechanism, so we are trying to
> use the normal mechanism whenever possible. When that fails, we can use our
> more expensive (but also more robust) resolution.
>
> The question is: What is the most effective way to do this? The EMF team
> has done an exemplary job at building in extensibility, but unfortunately
> that can make it challenging to decide how to extend.
>
> To us, the only place that makes sense is to override the
> 'ResourceSet.getEObject(URI,boolean)' method to:
> 1) Call 'ResourceSet.getResource(URI,false)' using the URI without its
> fragment. If the result is non-null, then the Resource exists in the
> ResourceSet, so try to resolve the fragment portion of the URI. Return
> either null if the fragment doesn't resolve, or the EObject from the
> resolution of the fragment. If , then continue.
> 2) The result from 'ResourceSet.getResource(URI,false)' returned null, so
> either the underlying resource is available but has not yet been needed (and
> no Resource exists for it), or there isn't even an underlying resource
> (i.e., the URI is bad). In either case, call
> 'ResourceSet.getResource(URI,true)' within a try-catch. If there is no
> exception, continue with the resolution of the fragment and return either
> the resolved EObject or null. If there is an exception, then there is no
> underlying resource (is this assumption correct?), so return null.
>
> Thoughts?
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3FD90210.D8C5C873@ca.ibm.com...
> > Dennis,
> >
> > I'm not clear why the behavior is undesirable. A resource can fail to
> load for
> > many reasons and even failing to open a stream for the resource URI can
> happen
> > for many reasons. It seems better to create a resource that records the
> failure
> > and acts as a placeholder so that other proxies into the same resource
> will fail
> > that much faster. Having a record of all the required resources seems
> like such
> > a good thing. Are you sure you really need to be doing something to
> change
> > this?
> >
> >
> > dfuglsang wrote:
> >
> > > Ed,
> > >
> > > I am running into a problem in which I am trying to resolve an eProxy to
> a
> > > resource that no longer exists. The problem, as I see it, is that the
> > > EcoreUtil.resolve(...):EObject methods end up creating a new empty
> resource
> > > when the URI of the eProxy is not found. This doesn't seem like a
> > > desirable behavior. EcoreUtil.resolve(...) calls
> > > ResourceSet.getEObject(URI,true) which, for my situation, ends up
> creating a
> > > new resource for that URI. An exception is then thrown when the
> > > ResourceSetImpl.demandLoad() is called within
> > > ResourceSetImpl.getResource(URI,true) because there is no underlying
> file
> > > for that URI.
> > >
> > > Is there a better way to check for the existence of the underlying file
> > > prior to creating the new resource? Should I be overriding the
> getEObject
> > > method ?
> > >
> > > Thanks in advance.
> > >
> > > Dennis
> >
|
|
|
| Re: Resolving a proxy using EcoreUtil.resolve [message #380969 is a reply to message #380968] |
Mon, 15 December 2003 09:22 |
| Eclipse User |
|
|
|
Right. I was talking with Dennis about this, and we just caught that as
well.
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3FDDC322.F1EAD3BF@ca.ibm.com...
> Randall,
>
> The algorithm you describe below will still demand create a resource in
the
> failure case. And no matter what you do, the possible reasons for failure
of
> ResourceSet.getResource is unbounded. The path of least resistance seems
to be
> to remove the failed resource as part of cleaning up the proxies that
reference
> it. Once the proxies are gone, the resource can be removed and will never
come
> back...
>
>
> Randall Hauch wrote:
>
> > We're attempting to handle the case when the resource has been moved so
that
> > it effectively has a new URI. (Picture moving or renaming an XMI file
in
> > the Eclipse workbench.) When a model has a reference to the moved
resource,
> > it still may have the old URI; this is where we've been trying to use
> > EcoreUtil.resolve(...):EObject. We have other ways of finding which XMI
> > file actually contains the object the proxy is pointing to. This
mechanism,
> > however, is more expensive than the normal mechanism, so we are trying
to
> > use the normal mechanism whenever possible. When that fails, we can use
our
> > more expensive (but also more robust) resolution.
> >
> > The question is: What is the most effective way to do this? The EMF
team
> > has done an exemplary job at building in extensibility, but
unfortunately
> > that can make it challenging to decide how to extend.
> >
> > To us, the only place that makes sense is to override the
> > 'ResourceSet.getEObject(URI,boolean)' method to:
> > 1) Call 'ResourceSet.getResource(URI,false)' using the URI without its
> > fragment. If the result is non-null, then the Resource exists in the
> > ResourceSet, so try to resolve the fragment portion of the URI. Return
> > either null if the fragment doesn't resolve, or the EObject from the
> > resolution of the fragment. If , then continue.
> > 2) The result from 'ResourceSet.getResource(URI,false)' returned null,
so
> > either the underlying resource is available but has not yet been needed
(and
> > no Resource exists for it), or there isn't even an underlying resource
> > (i.e., the URI is bad). In either case, call
> > 'ResourceSet.getResource(URI,true)' within a try-catch. If there is no
> > exception, continue with the resolution of the fragment and return
either
> > the resolved EObject or null. If there is an exception, then there is
no
> > underlying resource (is this assumption correct?), so return null.
> >
> > Thoughts?
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3FD90210.D8C5C873@ca.ibm.com...
> > > Dennis,
> > >
> > > I'm not clear why the behavior is undesirable. A resource can fail to
> > load for
> > > many reasons and even failing to open a stream for the resource URI
can
> > happen
> > > for many reasons. It seems better to create a resource that records
the
> > failure
> > > and acts as a placeholder so that other proxies into the same resource
> > will fail
> > > that much faster. Having a record of all the required resources seems
> > like such
> > > a good thing. Are you sure you really need to be doing something to
> > change
> > > this?
> > >
> > >
> > > dfuglsang wrote:
> > >
> > > > Ed,
> > > >
> > > > I am running into a problem in which I am trying to resolve an
eProxy to
> > a
> > > > resource that no longer exists. The problem, as I see it, is that
the
> > > > EcoreUtil.resolve(...):EObject methods end up creating a new empty
> > resource
> > > > when the URI of the eProxy is not found. This doesn't seem like a
> > > > desirable behavior. EcoreUtil.resolve(...) calls
> > > > ResourceSet.getEObject(URI,true) which, for my situation, ends up
> > creating a
> > > > new resource for that URI. An exception is then thrown when the
> > > > ResourceSetImpl.demandLoad() is called within
> > > > ResourceSetImpl.getResource(URI,true) because there is no underlying
> > file
> > > > for that URI.
> > > >
> > > > Is there a better way to check for the existence of the underlying
file
> > > > prior to creating the new resource? Should I be overriding the
> > getEObject
> > > > method ?
> > > >
> > > > Thanks in advance.
> > > >
> > > > Dennis
> > >
>
|
|
|
Goto Forum:
Current Time: Thu Nov 06 14:16:21 EST 2025
Powered by FUDForum. Page generated in 0.03875 seconds |
Home