FWIW, if you need to set the TCCL in OSGi, the Apache Aries SPI Fly component may be of help: http://aries.apache.org/modules/spi-fly.html
Best regards, David On 6 September 2016 at 19:07, Raymond Auge <[email protected]> wrote: > 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) >
