The issue remains with libraries designed for Java EE, they use TCCL themselves because this has been forced upon them.
You'll have to do as David suggested and use SPI-Fly providing the requirements and capabilities to the bundles in question to ensure that the SPY-fly can wire the bundles together properly and do the instrumentation necessary to make it all work. - Ray On Tue, Sep 6, 2016 at 2:50 PM, Alessandro Gherardi < [email protected]> wrote: > > Thanks. > However, my application is NOT running within a J2EE container - it's a > stand-alone, J2SE application started via java -cp ... path.to.main.class. > > > > From: Raymond Auge <[email protected]> > To: felix users <[email protected]>; Alessandro Gherardi < > [email protected]> > Sent: Tuesday, September 6, 2016 12:07 PM > Subject: Re: Issues with embedded Felix framework and JAXRS > > Context classloaders are an Java EE construct and not something that OSGi > frameworks usually care about. Therefore, when running OSGi embedded in a > JavaEE container you generally need to do all the work to ensure TCCL's are > properly handled. > > Sincerely, > - Ray > > On Tue, Sep 6, 2016 at 12:46 PM, Alessandro Gherardi < > [email protected]> wrote: > > > 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 > > | | > > > > | > > > > | > > > > > > > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> > (@OSGiAlliance) > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
