Hi, I read the launching/embedding page, but it was a few weeks ago and I will go back and take another look... I went with the Sahoo's suggestion of setting the delegation property and that is perfect for my needs... I agree I don't want any code outside of a bundle, if at all possible... Unfortunately, my parent has to do some "delegation" of its own -- but only to the very top API of my cache bundle interface... hence, my parent is a "medium" in a sense, where I get external requests and pass them through to the top level service api.... At that point, it's all OSGi based bundles... Otherwise, I'd be doing some other means to get from the external to the top level service bundle, like RMI or socket or other non-lightweight message passing means... By just adding my top level service api (which is nothing more than an interface and bundle thereof) to the config.properties delegation list, I think I'm golden... and, yes, if that interface changes, my parent must change too... I can live with that... however, I can make non-interface changes to the impl and not have to touch the parent, even at run time -- still pretty cool! Thanks to Angelo for the code snippet on the reflection... I would never have figured that out on my own... I entertained my thoughts and quickly went down the reflection path and I basically got wrapped up in 'Class', 'Method' and the like (I hate to admit this, but I'm pretty good with JNI... I didn't like the Sun tutorial and I wrote my own 60 page power point briefing on JNI... a sort of how to cheat sheet... I learned all about reflection by doing JNI); But, I didn't want to go to this much trouble... in the end, delegation worked just fine for me... Thanks again for all your help... this is good discussion stuff... Craig PS - If anyone would like a copy of my JNI briefing, just holler...
________________________________ From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Tue 7/8/2008 3:54 PM To: [email protected] Subject: Re: brain teaser - embedded felix / class cast exception Craig, Not sure if you read this document: http://cwiki.apache.org/FELIX/launching-and-embedding-apache-felix.html But this document discusses these issues and touches upon the various solutions/approaches, such as reflection. However, I am in agreement with the others, your life will be greatly simplified if you can package everything as bundles. -> richard Angelo van der Sijpt wrote: > Hi, > > On 8 Jul 2008, at 19:19, Dieter Wimberger wrote: > >> I guess that 7.0 is the output from the felix classloader. When >> allowing parent delegation (what Sahoo suggested), then you get the >> result you were looking for. > > The 7.0 is indeed the name of the classloader of bundle ID 7 (the 0 is > the version; if the bundle gets updated, this number will be > incremented), which has to be the bundle that exports the > CacheServiceMain object. > >> On 8 Jul 2008, at 18:47, Sahoo wrote: >>>> My parent is what creates the Felix container, so it is technically >>>> not >>>> in a bundle, but I loaded the same class code in it's jar (since I'm >>>> going to be using it, of course) -- although, design wise, I'm >>>> using the >>>> <<interface>> not the <<Impl>>, but I short circuited the interface >>>> just >>>> to get to the bottom of the riddle... >>> This seems to be the problem. Felix does not use the class that's >>> loaded by your code, which is running outside Felix. To fix it, you >>> have to make both Felix and your code use the same class. Since your >>> code runs before Felix and you probably don't want to use reflection >>> to use that class, the only option that I can think of is to >>> configure Felix to use your class by adding org.craig.cache to the >>> list of packages exported by the parent class loader. The property >>> name in config.property is: org.osgi.framework.system.packages. See >>> OSGi documentation for more details about this property. > > > True: Felix is a bundle too (that is why you can get its > BundleContext), the system bundle to be precise. This system bundle > does import the package from bundle 7 as soon as that class would get > used. You can get the service reference for the class you want because > it is possible to resolve the package import from the system bundle > (that is, if it would not be possible because of e.g. versioning, you > would not get the service reference). > > If you really want to use the service outside of the Felix instance, > Sahoo's suggestion of delegating to the system classloader seems the > best way to go. > Still, I think I would package whatever it is you want to be using > service with as a bundle, and run all code from inside that bundle. > > If neither of these is an option, reflection might help you out. For > instance, if you have a service MyService of which you are sure the > definitions are identical, but just not loaded by the same > classloader, you can use a proxy like such: > > final Object object = > bc.getService(bc.getServiceReference(MyService.class.getName())); > > MyService service = (MyService) > Proxy.newProxyInstance(MyService.class.getClassLoader(), new Class[] { > MyService.class }, > new InvocationHandler() { > public Object invoke(Object proxy, Method method, Object[] > args) throws Throwable { > Method bridge = > object.getClass().getDeclaredMethod(method.getName(), > method.getParameterTypes()); > return bridge.invoke(object, args); > } > }); > > > Hope this helps, > > Angelo
