Thank you.
One more question: If I only want to include one service in SPI-Provider -
i.e., no * wildcard - should I set SPI-Provider to the name of the file under
META-INF/services, or to the name of the class contained in that file?
For instance, say I have META-INF/services/org.apache.cxf.bus.factory, and that
file contains org.apache.cxf.bus.spring.SpringBusFactory .
Should I set:
SPI-Provider: org.apache.cxf.bus.factory
or
SPI-Provider: org.apache.cxf.bus.spring.SpringBusFactory
From: Raymond Auge <[email protected]>
To: felix users <[email protected]>; Alessandro Gherardi
<[email protected]>
Sent: Tuesday, September 6, 2016 1:08 PM
Subject: Re: Issues with embedded Felix framework and JAXRS
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)
