Re: ApplicationConfig and OSGi

  • From: Bill Burke <bburke@...>
  • To: users@...
  • Subject: Re: ApplicationConfig and OSGi
  • Date: Thu, 24 Jul 2008 10:25:47 -0400
  • Mailing-list: contact users-help@...; run by ezmlm



Paul Sandoz wrote:
Hi Reto,

Reto Bachmann-Gmür wrote:
Hello

Trying to use jax-rs in an OSGi environment we imagine bundles providing web applications by exposing instances of ApplicationConfig. However the jsr311 implementation residing in another bundle cannot instantiate the classes of the bundle providing the application.


I know very little about the technical aspects of OSGi but would not the same problem occur for a web application bundle referring to a servlet class in the web.xml that needs to be instantiated by servlet implementation residing in a different bundle?

And also for Web service endpoints, EJBs and JAXB beans when unmarshalling.


Why wouldn't JAX-RS be able to instantiate instances in an OSGi environment? You are getting actual references to classes and the JAX-RS runtime could do:

pushClassLoader(resourceClass.getClassLoader());

Object resource = resourceClass.instance();
invoke();

popClassLoader();

If all else fails, you could change your OSGi bundle to export the required classes.

In JBoss, each deployed bundle has its own classloader assigned to it (either a unique one or shared one depending on configuration). We register this classloader along with component metadata on deployment (components like EJB, Spring, etc.) to the subsystems that manage the deployment (like an EJB container). I can't really speak to how other OSGi and OSGi-like implementation would work, but there are very few ways to skin a cat.

Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com





ApplicationConfig and OSGi

Reto Bachmann-Gmür 07/24/2008

Re: ApplicationConfig and OSGi

Paul Sandoz 07/24/2008

Re: ApplicationConfig and OSGi

Bill Burke 07/24/2008

Re: ApplicationConfig and OSGi

Reto Bachmann-Gmür 07/28/2008

Re: ApplicationConfig and OSGi

Reto Bachmann-Gmür 07/24/2008
Terms of Use; Privacy Policy; Copyright ©2013-2016 (revision 20160708.bf2ac18)
 
 
Close
loading
Please Confirm
Close