Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370859

Summary:

Modeler hangs when model contains an 'implementationRef' QName on the Interface component

Product:

[SOA] BPMN2Modeler

Reporter:

Gary Brown <gary>

Component:

Assignee:

Robert Brodt <bbrodt>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

bbrodt

Version:

unspecified

Target Milestone:

0.0.1-M1

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
Model demonstrating the hang problem	none

Description Gary Brown

2012-02-07 12:48:10 EST

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

Comment 1 Gary Brown

2012-02-07 12:50:28 EST

Created attachment 210669 [details]
Model demonstrating the hang problem

Comment 2 Robert Brodt

2012-05-31 16:49:08 EDT

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

Comment 3 Robert Brodt

2012-05-31 17:03:07 EDT

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.

Comment 4 Gary Brown

2012-06-01 03:30:31 EDT

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?

Comment 5 Gary Brown

2012-06-01 03:31:55 EDT

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.

Comment 6 Robert Brodt

2012-06-01 08:19:58 EDT

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

Comment 7 Gary Brown

2012-06-01 08:29:13 EDT

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.

Comment 8 Robert Brodt

2012-06-20 14:55:08 EDT

Added a connection timeout user preference to avoid waiting forever for non-existent EMF resources.