Hi Guillaume, I did some works[1] about moving the OSGI stuff from camel-core to OSGI. Current Camel 1.6 and Camel 2.0-snapshot don't check the "getBundle" method from the classloader to verify if the camel context is deploied in an OSGI envrionment.
Please feel free to try them out. BTW, current we are voting the camel 1.6, you can get it from here[2] [1]http://issues.apache.org/activemq/browse/CAMEL-1043 [2]http://people.apache.org/~hadrian/apache-camel-1.6.0-RC1/maven2/ Willem Guillaume Renault wrote: > Hello all, > > it is time for me to inform the Camel users that i did some work on > Camel/OSGi/JOnAS. > > The goal was to provide a Camel OSGi service on the JOnAS 5 Application > Server. I first noticed that Camel provides bundles of its modules > (thanks all for this). However, an issue remains when we use Camel on > OSGi. In the camel-core, when Camel try to find the converters (and more > generally, when Camel try to deal with bundles), it needs to get the > list of bundles on the OSGi gateway. this is done this way : > > class : org.apache.camel.util.ResolverUtil > ... > org.osgi.framework.Bundle bundle = > (org.osgi.framework.Bundle) mth.invoke(loader); > org.osgi.framework.Bundle[] bundles = > bundle.getBundleContext().getBundles(); > ... > > where mth is a Method object and loader a ClassLoader. This is not a > common way to access the bundle list (so the bundleContext), as the > classloader doesn't own such a method by default. It must be done the > way it is in your case because of the websphere integration, but in a > common environment, Camel needs to access this list through the > BundleContext, which is known when the bundle is deployed on the gateway. > > Then i did some overload of the core to correctly get the bundles' list, > as it is impossible for Camel to know that we are in an OSGi environment > if the "getBundle" method is not available on a classloader. > > Once this was done, it was quite simple to provide a Camel service on an > OSGi gateway using iPOJO > (http://felix.apache.org/site/ipojo-concepts-overview.html). Be aware > that my work was done for integration on a JOnAS Application Server (it > is the reason of the classes' names), but it can perfectly work on a > "standalone" OSGi gateway without JOnAS (JOnAS 5 uses Felix by default). > > You can checkout the sources here > <svn://svn.forge.objectweb.org/svnroot/jonas/sandbox/camel-jonas5>. Feel > free to make comments, and if you're in need for such a service in > Camel, i will be glad to include my work in the project, either as an > example, or all other ways you would like to. Two examples are also > provided in my project, one deeling with JMS (using the JORAM > implementation) and an other one using CXF. > > I still need to set up some tests to validate my work in a unitary test way. > > BTW, i use from the version 1.5.0 of Camel. > > Feel free to comment this e-mail, and react on the subject. Also don't > hesitate to directly contact me. > > Regards, > > Guillaume > > PS : I'm using the Registry component made by S. Ali Tokmen, who made > Camel work on a JOnAS 4.10.3 version. This component allow to define > logical names to access endpoints when we define the camel routes. Those > names are binded to the real technical name. > > -- > Guillaume Renault - BULL Service > BULL - Architect of an Open World > Email : guillaume.rena...@bull.net > Tel : +334 76 29 71 09 > Office : B1-295 > Web : http://jasmine.ow2.org > web : http://jonas.ow2.org > (\ _ /) > (='.'=) > (")-(") >
