|
|
| Re: Fast & loud proxy resolution failure [message #528305 is a reply to message #528154] |
Tue, 20 April 2010 06:15   |
 Caspar D.
Messages: 35
Registered: July 2009 |
Member |
|
|
Ed,
Thanks for your response, see my additional comments below.
>> Is there a way of having proxy resolution fail loud and
>> fast, instead of silently and slowly?
>>
>> Calling any of the ECoreUtil.resolve* methods seems to
>> (a) attempt to create and load a resource for the URI
>> passed, if it's not already present (instead I would like
>> it to fail immediately if the resource isn't present)
> The resource will always be created and then will attempt
> to load. You can scan the resource set and look at each
> resource's getErrors to see which ones represent bogus
> attempts to load a resource that fails for one reason or
> another.
Yes, but the load attempt is exactly what I'd like to avoid,
since it could be slow (especially if the URI's scheme is
http) and I know it will fail anyway. I'm dealing with
interdependent packages, and if the ResourceSet can't find
the nsURI in the package registry (via
delegatedGetResource), I want it to just give up instead of
attempt to load over the network.
>> and
>>
>> (b) snuff the exception when resolution fails, and return the proxy
>> (instead I'd like to know about the resolution failure.)
> It already does that.
You mean snuff the exception and return the proxy? Yes, but
that's the behavior I don't want. I would prefer to
receive the exception immediately...
> There's the unresolved proxy cross referencer you can use
> to find all broken proxies...
True, but it seems that would requires two scans of the data
tree: one to attempt resolution of all proxies, and another
to find the ones that couldn't be resolved. I was wondering
if there is a more efficient way.
Thanks
/Caspar
|
|
|
| Re: Fast & loud proxy resolution failure [message #528385 is a reply to message #528305] |
Tue, 20 April 2010 10:48 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Caspar,
Comments below.
Caspar De Groot wrote:
> Ed,
> Thanks for your response, see my additional comments below.
>
>>> Is there a way of having proxy resolution fail loud and
>>> fast, instead of silently and slowly?
>>>
>>> Calling any of the ECoreUtil.resolve* methods seems to
>>> (a) attempt to create and load a resource for the URI
>>> passed, if it's not already present (instead I would like
>>> it to fail immediately if the resource isn't present)
>
>> The resource will always be created and then will attempt
>> to load. You can scan the resource set and look at each
>> resource's getErrors to see which ones represent bogus
>> attempts to load a resource that fails for one reason or
>> another.
>
> Yes, but the load attempt is exactly what I'd like to avoid,
> since it could be slow (especially if the URI's scheme is
> http) and I know it will fail anyway. I'm dealing with
> interdependent packages, and if the ResourceSet can't find
> the nsURI in the package registry (via
> delegatedGetResource), I want it to just give up instead of
> attempt to load over the network.
You could (would need to) specialize your ResourceSetImpl for that.
Note that loading only fails once per resource...
>
>>> and
>>>
>>> (b) snuff the exception when resolution fails, and return the proxy
>>> (instead I'd like to know about the resolution failure.)
>
>> It already does that.
>
> You mean snuff the exception and return the proxy? Yes, but
> that's the behavior I don't want. I would prefer to
> receive the exception immediately...
This seems to contradict your earlier statement. eResolveProxy is
called on the EObject that holds the proxy, so you could throw
exceptions whenever that is going to return a proxy.
>
>> There's the unresolved proxy cross referencer you can use
>> to find all broken proxies...
>
> True, but it seems that would requires two scans of the data
> tree: one to attempt resolution of all proxies, and another
> to find the ones that couldn't be resolved. I was wondering
> if there is a more efficient way.
Are you really dealing with a situation where you'd notice it was 10
times slower? Could you notice there are failed resources and only then
look for proxies.
>
> Thanks
> /Caspar
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03316 seconds
] 
Search
Help
Register
Login
Home
