I've been tasked with updating a plugin for Cytoscape, a biological visualization software platform, to the latest version of the Cytoscape API. Cytoscape 3.x uses an OSGI framework (Karaf 2.2.x, I think) to interface with its plugins (which are now called "apps").
The problem is that the plugin/app uses JAX-WS to communicate with an external server, and JAX-WS seems to have problems with loading classes in the OSGI environment.
Here is a snippet of the problematic code:
public class AnatServerService extends Service {
@WebEndpoint(name = "AnatServerPort")
public AnatServerIfc getServerPort() {
AnatServerIfc port = super.getPort(new QName("network", "AnatServerPort"), AnatServerIfc.class);
((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, path);
return port;
}
}
And here is the resulting exception:
java.lang.NoClassDefFoundError: com.sun.xml.internal.ws.api.message.Header not found by AnatApp [168]
at com.sun.proxy.$Proxy64.<clinit>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.reflect.Proxy.newInstance(Unknown Source)
at java.lang.reflect.Proxy.newProxyInstance(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.internal.ws.client.WSServiceDelegate.createProxy(UnknownSource)
at com.sun.xml.internal.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at javax.xml.ws.Service.getPort(Unknown Source)
at anat.ws.AnatServerService.getServerPort(AnatServerService.java:36)
at anat.task.AvailableNetworksTask.getAvailableNetworks(AvailableNetworksTask.java:39)
at anat.task.AvailableNetworksTask.run(AvailableNetworksTask.java:62)
at org.cytoscape.work.internal.sync.SyncTaskManager.execute(SyncTaskManager.java:86)
at anat.view.BackgroundDefinitionDialog$AvailableNetworksSwingWorker.doInBackground(BackgroundDefinitionDialog.java:1544)
at anat.view.BackgroundDefinitionDialog$AvailableNetworksSwingWorker.doInBackground(BackgroundDefinitionDialog.java:1535)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I can confirm that this code does work outside of OSGI.
Any suggestions? I've tried experimenting with embedding the JAX-WS API and/or implementation classes directly into the bundle using Embed-Dependency, but that didn't help. I've also tried playing with the org.osgi.framework.system.packages.extra and org.osgi.framework.bootdelegation properties, to no avail. It is possible that I'm doing something wrong, though.
I'm afraid that OSGI might have some fundamental incompatibility with the Reflection API being used to create that header. But surely it can't be impossible to run a web service client in this environment, right?
I've solved my own problem. It turns out I had edited the org.osgi.framework.bootdelegation property in the wrong file - config.properties instead of custom.properties.
This is still a problem in the long term, though. I'd like to be able to distribute this bundle without requiring users to edit config files.