Bug 402616 - [EMF Runtime Extensions] Improve ProxyResolutionBehavior
Summary: [EMF Runtime Extensions] Improve ProxyResolutionBehavior
Status: CLOSED WONTFIX
Alias: None
Product: Sphinx
Classification: Automotive
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P1 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-07 03:35 EST by Robert Kiss CLA
Modified: 2024-05-07 00:57 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Kiss CLA 2013-03-07 03:35:58 EST
Resolving a proxy could be a very expensive operation. Depending on the type of the model used and how the references are actually made, a more efficient algorithm can be implemented. The current possibility to come with an algorithm by using the  (deprecated) ProxyHelper might not be sufficient as it have access only to the proxyURI.

For example, in the context of Artop, if a proxy is already checked and not resolved and if the resourcesSet has not been changed in the meantime, is not necessary to try again to resolve the proxy.

I propose to move the entire logic to the ProxyHelper or similar. A pseudocode of eResolveProxyInResourceSet could look like:

if(proxyHelper != null){
  return proxyHelper.resolveProxy(resourceSet, contextObject, proxy)
} else {
  // Delegate to conventional EMF proxy resolution;
  // it may be able to do the job
  return resourceSet.getEObject(proxyURI, true);
}

All the logic regarding black list and ScopingResourceSet will be moved to the Sphinx implementation of ProxyHelper.
Comment 1 Stephan Eberle CLA 2013-05-30 11:30:03 EDT
I agree with that all the logic that is related to lookup resolver, proxy blacklist, and flag to ignore fragment-based proxies should be moved to and centralized on the ProxyHelper adapter.

However, we must keep bug #409510 in mind. As a consequence, all the things that are currently done in ScopingResourceSetImpl#getEObjectInScope() should leave where they are right now and not be moved to the ProxyHelper as well.
Comment 2 Stephan Eberle CLA 2013-10-01 09:39:29 EDT
Meanwhile bug # 409510 has been fixed. As a consequence, the code where the ProxyHelper adapter is used has been slightly reorganized. Most importantly, the invocation of the ProxyHelper adapter has been moved from ScopingResourceSetImpl to ExtendedResourceSetImpl#getEObjet() and the signature of the ExtendedResourceSetImpl#getEObjet() method has been changed to ExtendedResourceSetImpl#getEObjet(EObject proxy, EObject contextObject, boolean loadOnDemand). Could you please revise your patch and attach a new version that reflects the changed introduced through above mentioned bug, please?

Thanks.
Comment 3 Balazs Grill CLA 2024-05-07 00:57:14 EDT
Closed stale issue before migration