Community
Participate
Working Groups
Build Identifier: The 'implementationRef' property is used to contain implementation specific type information associated with an interface. When a model contains this field, the modeler appears to hang. Reproducible: Always
Created attachment 210669 [details] Model demonstrating the hang problem
It looks like the EMF proxy resolver uses java.net.URL to open the (remote) URL and since some of these are just URIs (like, e.g. "http://www.jboss.org/examples/store") the connection waits forever. A simple fix is to change the sun.net.client.defaultConnectTimeout system property to a more reasonable value. Another option is to provide our own URI converter in the ResourceSet (see ResourceSet#getURIConverter()) and set a more reasonable timeout there, or use an alternative to java.net.URL to load the resource. See http://stackoverflow.com/questions/5351689/alternative-to-java-net-url-for-custom-timeout-setting
It looks like this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=286640 isn't going to happen, but there's some good info there. How about adding a URI list to the BPMN2 Modeler User Preferences that are used as namespace URIs only. These would then be ignored by the custom URI converter and would simply be treated as unresolved proxies by the editor.
The implementationRef is a QName, so the namespace shouldn't be treated as a URL. To resolve to a WSDL interface, the namespace could be used to check for an import associated with the same namespace and then get the URL from the location?
However, just realized, unless you are doing some validation that the interface exists, then you wouldn't actually need to resolve the implementation - and this validation could simply be done for the import element, to check that its location points to a valid resource.
This all goes back to the fact that ImplementationRef.structureRef is defined to be an EObject. In order to allow arbitrary strings to be stored in this EObject (as required by jBPM), it's necessary to create a proxy object which, in this case, is qualified with a ns prefix. EMF automatically tries to resolve these proxies, by loading the remote resource which does not exist, hence the socket blocks waiting on the connection. I've tried changing the timeout to several seconds, which does appear to work and the process file loads successfully without errors being reported. So, EMF can still work with these objects as proxies. Maybe calling setResolveProxies(false) on these will fix the problem. See http://download.eclipse.org/modeling/emf/emf/javadoc/2.4.2/org/eclipse/emf/ecore/EReference.html#setResolveProxies%28boolean%29
Just depends whether we might need to reference objects across bpmn2 models later on? Not sure whether it would be useful for the editor to be unaware that an object has been loaded from a different emf model. Maybe try with this property as false for now, but might need to be revisited if cross-model editing is required.
Added a connection timeout user preference to avoid waiting forever for non-existent EMF resources.
