You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by Guillaume Renault <gu...@bull.net> on 2009/02/13 17:42:13 UTC

Camel as an OSGi service on a JOnAS 5.1.0-M3 Application Server

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.renault@bull.net
Tel : +334 76 29 71 09
Office : B1-295
Web : http://jasmine.ow2.org
web : http://jonas.ow2.org
(\ _ /)
(='.'=)
(")-(")

Re: Camel as an OSGi service on a JOnAS 5.1.0-M3 Application Server

Posted by Guillaume Renault <gu...@bull.net>.

Hi all,

I just provided a test to my Camel service, in a simple OSGi gateway out 
of a JOnAS environment. You can check it, it may give some ideas.
Here <svn://svn.forge.objectweb.org/svnroot/jonas/sandbox/camel-jonas5> 
are the sources to checkout.

Guillaume

Guillaume Renault a écrit :
> Hi Willem,
>
> i'll check your work as soon as i can :), and test it, thx. However, 
> i'm not sure i'll be able to do it before the 1.6.0 release.
>
> I also saw the CAMEL-1345 report on JIRA. A way to make things become 
> easier for the users could be to provide a Camel service when its 
> bundle is installed and started on an OSGi gateway. It's the way i 
> did, using iPOJO 
> <http://felix.apache.org/site/apache-felix-ipojo.html> as the OSGi 
> service manager.
>
> Cheers,
>
> Guillaume
>
> Willem Jiang a écrit :
>> 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.renault@bull.net
>>> Tel : +334 76 29 71 09
>>> Office : B1-295
>>> Web : http://jasmine.ow2.org
>>> web : http://jonas.ow2.org
>>> (\ _ /)
>>> (='.'=)
>>> (")-(")
>>>
>>>     
>>
>>
>>
>>   
>
>
> -- 
> Guillaume Renault - BULL Service
> BULL - Architect of an Open World
> Email : guillaume.renault@bull.net
> Tel : +334 76 29 71 09
> Office : B1-295
> Web : http://jasmine.ow2.org
> web : http://jonas.ow2.org
> (\ _ /)
> (='.'=)
> (")-(")
>   


-- 
Guillaume Renault - BULL Service
BULL - Architect of an Open World
Email : guillaume.renault@bull.net
Tel : +334 76 29 71 09
Office : B1-295
Web : http://jasmine.ow2.org
web : http://jonas.ow2.org
(\ _ /)
(='.'=)
(")-(")

Re: Camel as an OSGi service on a JOnAS 5.1.0-M3 Application Server

Posted by Guillaume Renault <gu...@bull.net>.

Hi Willem,

i'll check your work as soon as i can :), and test it, thx. However, i'm 
not sure i'll be able to do it before the 1.6.0 release.

I also saw the CAMEL-1345 report on JIRA. A way to make things become 
easier for the users could be to provide a Camel service when its bundle 
is installed and started on an OSGi gateway. It's the way i did, using 
iPOJO <http://felix.apache.org/site/apache-felix-ipojo.html> as the OSGi 
service manager.

Cheers,

Guillaume

Willem Jiang a écrit :
> 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.renault@bull.net
>> Tel : +334 76 29 71 09
>> Office : B1-295
>> Web : http://jasmine.ow2.org
>> web : http://jonas.ow2.org
>> (\ _ /)
>> (='.'=)
>> (")-(")
>>
>>     
>
>
>
>   


-- 
Guillaume Renault - BULL Service
BULL - Architect of an Open World
Email : guillaume.renault@bull.net
Tel : +334 76 29 71 09
Office : B1-295
Web : http://jasmine.ow2.org
web : http://jonas.ow2.org
(\ _ /)
(='.'=)
(")-(")

Re: Camel as an OSGi service on a JOnAS 5.1.0-M3 Application Server

Posted by Willem Jiang <wi...@gmail.com>.

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.renault@bull.net
> Tel : +334 76 29 71 09
> Office : B1-295
> Web : http://jasmine.ow2.org
> web : http://jonas.ow2.org
> (\ _ /)
> (='.'=)
> (")-(")
>