felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Gherardi <alessandro.ghera...@yahoo.com.INVALID>
Subject Issues with embedded Felix framework and JAXRS
Date Tue, 06 Sep 2016 16:46:38 GMT
Hi,I have a non-OSGi Java app that loads an OSGi bundle by embedding Felix. The bundle exposes
its functionality as an OSGi service. The app accesses the service via a service tracker. The
app uses the org.osgi.framework.system.packages.extra option so that the service interface
and the classes that the interfaces refers to are all loaded by the same classloader in
both the app and the bundle.
The bundle uses Jersey 2.X and the app uses Jersey 1.17. When the app calls the bundle via
the service, the Jersey 2.X code throws the following exception:
Exception in thread "main" java.lang.LinkageError: ClassCastException: attempting to castfile:/C:/XXX/bin/javax/ws/rs/ext/RuntimeDelegate.class
to bundle://59.1:1/javax/ws/rs/ext/RuntimeDelegate.classat javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:146)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:120) at javax.ws.rs.core.UriBuilder.newInstance(UriBuilder.java:95)...
Looking at the Jersey source code, it appears that RuntimeDelegate tries to load a concrete
subclass via javax.ws.rs.ext.FactoryFinder. FactoryFinder reads the name of the subclass from
file META-INF/services/javax.ws.rs.ext.RuntimeDelegate, and it loads that file via the calling
threads's context class loader. Since the calling thread is an application's thread, its class
loader is the application's class loader, so META-INF/services/javax.ws.rs.ext.RuntimeDelegate
points to a Jersey 1.17 class.
I can kind-of workaround the problem by setting the application thread to an "empty" class
loader before calling the service - i.e.:
ClassLoader saveCL = Thread.currentThread().getContextClassLoader();
ClassLoader myCL = new URLClassLoader(new URL[0], saveCL.getParent());
try {
  Thread.currentThread().setContextClassLoader(myCL);
  call OSGi service
} finally {
  Thrad.currentThread().setContextClassloader(saveCL);
}

However, I'm surprised I have to do that. Shouldn't the framework take care of this - even
if the service caller is the embedded application rather than another OSGi bundle?
Notice: This issue may or may not be related to  commons-logging and Axis problems
Thank you in advance,Alessandro
  
|  
|   
|   
|   |    |

   |

  |
|  
|   |  
commons-logging and Axis problems
   |   |

  |

  |

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message