Camel under OSGi without Spring et al.
Locked
12
12
Camel under OSGi without Spring et al.
 
|
Hi all,
I have an existing OSGi (Equinox) application into which I would like to introduce Camel. I'm quite new to Camel, but I've not had much luck with my efforts so far. My problem seems to match that which is discussed in this thread: http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment without one of those higher level abstractions? The resolution of that thread seems to be to "include Spring", but my application is not Spring-based, and I would prefer not to introduce that dependency if at all possible. Thanks in advance for your advice, + + + + + + + + + + + + + + + + Michael Furtak Software Engineer Cognitive Systems Government Services Charles River Analytics Inc. 617.491.3474 x534 www.cra.com<http://www.cra.com/> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. |
Re: Camel under OSGi without Spring et al.
|
Hi Michael,
Yes, it's possible. I do it myself. I create my routes in Java, and I use a service that supplies a singleton CamelContext based on OsgiDefaultCamelContext. What specific problems are you having? Don On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak <[hidden email]> wrote: > Hi all, > > I have an existing OSGi (Equinox) application into which I would like to introduce Camel. I'm quite new to Camel, but I've not had much luck with my efforts so far. My problem seems to match that which is discussed in this thread: > > http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html > > From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment without one of those higher level abstractions? The resolution of that thread seems to be to "include Spring", but my application is not Spring-based, and I would prefer not to introduce that dependency if at all possible. > > Thanks in advance for your advice, > > + + + + + + + + + + + + + + + + > Michael Furtak > Software Engineer > Cognitive Systems > Government Services > Charles River Analytics Inc. > 617.491.3474 x534 > www.cra.com<http://www.cra.com/> > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > > > |
RE: Camel under OSGi without Spring et al.
|
|
Hi Don,
The exception was: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] Which I assume has to do with trying to use a normal CamelContext in an OSGi environment. So, OsgiDefaultCamelContext... I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. Any further info would be most helpful. Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. -----Original Message----- From: Donald Whytock [mailto:[hidden email]] Sent: Monday, June 20, 2011 3:10 PM To: [hidden email] Subject: Re: Camel under OSGi without Spring et al. Hi Michael, Yes, it's possible. I do it myself. I create my routes in Java, and I use a service that supplies a singleton CamelContext based on OsgiDefaultCamelContext. What specific problems are you having? Don On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak <[hidden email]> wrote: > Hi all, > > I have an existing OSGi (Equinox) application into which I would like to introduce Camel. I'm quite new to Camel, but I've not had much luck with my efforts so far. My problem seems to match that which is discussed in this thread: > > http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html > > From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment without one of those higher level abstractions? The resolution of that thread seems to be to "include Spring", but my application is not Spring-based, and I would prefer not to introduce that dependency if at all possible. > > Thanks in advance for your advice, > > + + + + + + + + + + + + + + + + > Michael Furtak > Software Engineer > Cognitive Systems > Government Services > Charles River Analytics Inc. > 617.491.3474 x534 > www.cra.com<http://www.cra.com/> > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > > > |
|
Hi,
You are correct. There is also a camel-blueprint you may want to look at [1]. Regarding the absence of camel-core-osgi from the kit, that's actually a problem that was reported earlier today [2]. We use maven so much that we missed the absence of some of the jars from the official distro. Please grab the missing jars from the maven central repository [3] (and maybe [4]). Regards, Hadrian [1] http://camel.apache.org/using-osgi-blueprint-with-camel.html [2] https://issues.apache.org/jira/browse/CAMEL-4125 [3] http://repo1.maven.org/maven2/org/apache/camel/camel-core-osgi/2.7.2/ [4] http://repo1.maven.org/maven2/org/apache/camel/camel-core-xml/2.7.2/ On 06/20/2011 03:31 PM, Michael Furtak wrote: > Hi Don, > > The exception was: > > org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > > Which I assume has to do with trying to use a normal CamelContext in an OSGi environment. So, OsgiDefaultCamelContext... > > I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. > > Any further info would be most helpful. > > Thanks, > -Mike > > > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > -----Original Message----- > > > > From: Donald Whytock [mailto:[hidden email]] > Sent: Monday, June 20, 2011 3:10 PM > To: [hidden email] > Subject: Re: Camel under OSGi without Spring et al. > > Hi Michael, > > Yes, it's possible. I do it myself. I create my routes in Java, and > I use a service that supplies a singleton CamelContext based on > OsgiDefaultCamelContext. > > What specific problems are you having? > > Don > > On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak<[hidden email]> wrote: >> Hi all, >> >> I have an existing OSGi (Equinox) application into which I would like to introduce Camel. I'm quite new to Camel, but I've not had much luck with my efforts so far. My problem seems to match that which is discussed in this thread: >> >> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html >> >> From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment without one of those higher level abstractions? The resolution of that thread seems to be to "include Spring", but my application is not Spring-based, and I would prefer not to introduce that dependency if at all possible. >> >> Thanks in advance for your advice, >> >> + + + + + + + + + + + + + + + + >> Michael Furtak >> Software Engineer >> Cognitive Systems >> Government Services >> Charles River Analytics Inc. >> 617.491.3474 x534 >> www.cra.com<http://www.cra.com/> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> >> >> > |
Re: Camel under OSGi without Spring et al.
|
|
In reply to this post by Michael Furtak
Yeah, I had that. In an OSGi environment, you don't have
TypeConverters available until they've been registered as services by the Camel bundles. I built something that uses a ServiceTracker to listen for instances of org.apache.camel.spi.ComponentResolver. One is launched with the camel-core bundle; others are launched with the component bundles. You need there to be something that matches the filter "((&" + Constants.OBJECTCLASS + "=" + ComponentResolver.class.getName() + ")(component=" + <component name> + "))" So that you know all the components are there before you start apps that depend on them. I can attach a couple samples shortly. Don On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: > Hi Don, > > The exception was: > > org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > > Which I assume has to do with trying to use a normal CamelContext in an OSGi environment. So, OsgiDefaultCamelContext... > > I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. > > Any further info would be most helpful. > > Thanks, > -Mike > > > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > -----Original Message----- > > > > From: Donald Whytock [mailto:[hidden email]] > Sent: Monday, June 20, 2011 3:10 PM > To: [hidden email] > Subject: Re: Camel under OSGi without Spring et al. > > Hi Michael, > > Yes, it's possible. I do it myself. I create my routes in Java, and > I use a service that supplies a singleton CamelContext based on > OsgiDefaultCamelContext. > > What specific problems are you having? > > Don > > On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak <[hidden email]> wrote: >> Hi all, >> >> I have an existing OSGi (Equinox) application into which I would like to introduce Camel. I'm quite new to Camel, but I've not had much luck with my efforts so far. My problem seems to match that which is discussed in this thread: >> >> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html >> >> From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment without one of those higher level abstractions? The resolution of that thread seems to be to "include Spring", but my application is not Spring-based, and I would prefer not to introduce that dependency if at all possible. >> >> Thanks in advance for your advice, >> >> + + + + + + + + + + + + + + + + >> Michael Furtak >> Software Engineer >> Cognitive Systems >> Government Services >> Charles River Analytics Inc. >> 617.491.3474 x534 >> www.cra.com<http://www.cra.com/> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> >> >> > > |
RE: Camel under OSGi without Spring et al.
|
|
In reply to this post by hadrian
Hi Hadrian,
Aha, that explains it. Thanks! -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. -----Original Message----- From: Hadrian Zbarcea [mailto:[hidden email]] Sent: Monday, June 20, 2011 3:45 PM To: [hidden email] Subject: Re: Camel under OSGi without Spring et al. Hi, You are correct. There is also a camel-blueprint you may want to look at [1]. Regarding the absence of camel-core-osgi from the kit, that's actually a problem that was reported earlier today [2]. We use maven so much that we missed the absence of some of the jars from the official distro. Please grab the missing jars from the maven central repository [3] (and maybe [4]). Regards, Hadrian [1] http://camel.apache.org/using-osgi-blueprint-with-camel.html [2] https://issues.apache.org/jira/browse/CAMEL-4125 [3] http://repo1.maven.org/maven2/org/apache/camel/camel-core-osgi/2.7.2/ [4] http://repo1.maven.org/maven2/org/apache/camel/camel-core-xml/2.7.2/ On 06/20/2011 03:31 PM, Michael Furtak wrote: > Hi Don, > > The exception was: > > org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > > Which I assume has to do with trying to use a normal CamelContext in an OSGi environment. So, OsgiDefaultCamelContext... > > I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. > > Any further info would be most helpful. > > Thanks, > -Mike > > > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > -----Original Message----- > > > > From: Donald Whytock [mailto:[hidden email]] > Sent: Monday, June 20, 2011 3:10 PM > To: [hidden email] > Subject: Re: Camel under OSGi without Spring et al. > > Hi Michael, > > Yes, it's possible. I do it myself. I create my routes in Java, and > I use a service that supplies a singleton CamelContext based on > OsgiDefaultCamelContext. > > What specific problems are you having? > > Don > > On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak<[hidden email]> wrote: >> Hi all, >> >> I have an existing OSGi (Equinox) application into which I would like to introduce Camel. I'm quite new to Camel, but I've not had much luck with my efforts so far. My problem seems to match that which is discussed in this thread: >> >> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html >> >> From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment without one of those higher level abstractions? The resolution of that thread seems to be to "include Spring", but my application is not Spring-based, and I would prefer not to introduce that dependency if at all possible. >> >> Thanks in advance for your advice, >> >> + + + + + + + + + + + + + + + + >> Michael Furtak >> Software Engineer >> Cognitive Systems >> Government Services >> Charles River Analytics Inc. >> 617.491.3474 x534 >> www.cra.com<http://www.cra.com/> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> >> >> > |
Re: Camel under OSGi without Spring et al.
|
|
In reply to this post by Donald Whytock
OsgiCamelTracker.java (attached) is a work in progress. There's a
reference to ContextUtil; that's the service class that supplies the CamelContext singleton. Use it by subclassing it and implementing methods start() and stop(). Call setBundleContext(bundleContext) first, then startTracking(). OsgiCamelTracker.startTracking() accepts no parameters, a single String, or a Collection<String>. The strings are the names of components that you need. It'll track instances of ComponentResolver, maintaining a list of what components are available and what components are still needed. When all the components you need are available, it'll call start(); when any of the components cease to be available, it'll call stop(). If you don't supply component names, it'll react to camel-core itself becoming active, which is all you need for core components like mock, bean and file. Use routeId(<name>) in your route definitions. Use camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). Be advised, you'll need to use a singleton CamelContext if you're using SEDA queues, because SEDA queues are local to a CamelContext instance. A route that consumes from a SEDA queue from one CamelContext instance won't see anything produced to a SEDA queue from a different CamelContext instance. For OsgiDefaultCamelContext... > On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out into its own .jar so as to not worry about the Blueprint dependencies. You'll need to modify the manifest, or make your own. Don |
Re: Camel under OSGi without Spring et al.
|
In reply to this post by Michael Furtak
Just FYI, the camel-core-osgi bundle will be published in the Camel
2.8.0. You can find more information here[1] [1]https://issues.apache.org/jira/browse/CAMEL-3814 On 6/21/11 3:31 AM, Michael Furtak wrote: > i Don, > > The exception was: > > org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > > Which I assume has to do with trying to use a normal CamelContext in an OSGi environment. So, OsgiDefaultCamelContext... > > I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. > > Any further info would be most helpful. > > Thanks, > -Mike > -- Willem ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang |
Re: Camel under OSGi without Spring et al.
|
Hi Willem and Mike,
I just tried to use the OsgiDefaultCamelContext in OSGi. This is not directly possbile as the package is not exported. In the end I found that there is a CamelContextFactory in camel-spring that can be used to instantiate a camel context. It works like this in the Activator: CamelContextFactory factory = new CamelContextFactory(); factory.setBundleContext(context); DefaultCamelContext camelContext = factory.createContext(); I wonder a bit why this clearly OSGi specific class is in camel-spring. I would have expected it rather in camel-core-osgi. In any case it seems to be the only way to instantiate the camel context programmatically in OSGi. Christian Am 21.06.2011 04:51, schrieb Willem Jiang: > Just FYI, the camel-core-osgi bundle will be published in the Camel > 2.8.0. You can find more information here[1] > > [1]https://issues.apache.org/jira/browse/CAMEL-3814 > > On 6/21/11 3:31 AM, Michael Furtak wrote: >> i Don, >> >> The exception was: >> >> org.apache.camel.TypeConverterLoaderException: Failed to load type >> converters because of: Cannot find any type converter classes from >> the following packages: [org.apache.camel.component.file, >> org.apache.camel.component.bean, org.apache.camel.converter] >> >> Which I assume has to do with trying to use a normal CamelContext in >> an OSGi environment. So, OsgiDefaultCamelContext... >> >> I did come across mention of this in my troubleshooting exploration. >> It seems to be part of a bundle called camel-core-osgi, is that >> right? I don't think I have it in my 2.7.2 distribution. Is it >> something I need to bundle myself? I also saw mention of it being >> private to the Spring bundle, which is what prompted my discussion >> about not wanting to bring in Spring. >> >> Any further info would be most helpful. >> >> Thanks, >> -Mike >> > > -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com |
Re: Camel under OSGi without Spring et al.
|
|
Hi Christian
You can create the OsgiDefaultCamelContext directly when you install the camel-core-osgi bundle. DefaultCamelContext camelContext = new OsgiDefaultCamelContext(context); The CamelContextFactory is designed as a factory bean for spring to use. Willem On 6/21/11 1:23 PM, Christian Schneider wrote: > Hi Willem and Mike, > > I just tried to use the OsgiDefaultCamelContext in OSGi. This is not > directly possbile as the package is not exported. > In the end I found that there is a CamelContextFactory in camel-spring > that can be used to instantiate a camel context. > > It works like this in the Activator: > > CamelContextFactory factory = new CamelContextFactory(); > factory.setBundleContext(context); > DefaultCamelContext camelContext = factory.createContext(); > > I wonder a bit why this clearly OSGi specific class is in camel-spring. > I would have expected it rather in camel-core-osgi. > In any case it seems to be the only way to instantiate the camel context > programmatically in OSGi. > > Christian > > > Am 21.06.2011 04:51, schrieb Willem Jiang: >> Just FYI, the camel-core-osgi bundle will be published in the Camel >> 2.8.0. You can find more information here[1] >> >> [1]https://issues.apache.org/jira/browse/CAMEL-3814 >> >> On 6/21/11 3:31 AM, Michael Furtak wrote: >>> i Don, >>> >>> The exception was: >>> >>> org.apache.camel.TypeConverterLoaderException: Failed to load type >>> converters because of: Cannot find any type converter classes from >>> the following packages: [org.apache.camel.component.file, >>> org.apache.camel.component.bean, org.apache.camel.converter] >>> >>> Which I assume has to do with trying to use a normal CamelContext in >>> an OSGi environment. So, OsgiDefaultCamelContext... >>> >>> I did come across mention of this in my troubleshooting exploration. >>> It seems to be part of a bundle called camel-core-osgi, is that >>> right? I don't think I have it in my 2.7.2 distribution. Is it >>> something I need to bundle myself? I also saw mention of it being >>> private to the Spring bundle, which is what prompted my discussion >>> about not wanting to bring in Spring. >>> >>> Any further info would be most helpful. >>> >>> Thanks, >>> -Mike >>> >> >> > -- Willem ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang |
Re: Camel under OSGi without Spring et al.
|
|
Hi Willem,
that did not work for me. The bundle camel-core-osgi does not seem to export the package org.apache.camel.core.osgi. It is in Ignore-Packages. Christian Am 21.06.2011 09:39, schrieb Willem Jiang: > Hi Christian > > You can create the OsgiDefaultCamelContext directly when you install > the camel-core-osgi bundle. > > DefaultCamelContext camelContext = new OsgiDefaultCamelContext(context); > > The CamelContextFactory is designed as a factory bean for spring to use. > > Willem -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com |
Re: Camel under OSGi without Spring et al.
|
|
Please try the latest Camel 2.8-SNAPSHOT.
The patch wasn't merged to Camel 2.7.x. On 6/21/11 3:46 PM, Christian Schneider wrote: > Hi Willem, > > that did not work for me. The bundle camel-core-osgi does not seem to > export the package org.apache.camel.core.osgi. > It is in Ignore-Packages. > > Christian > > > Am 21.06.2011 09:39, schrieb Willem Jiang: >> Hi Christian >> >> You can create the OsgiDefaultCamelContext directly when you install >> the camel-core-osgi bundle. >> >> DefaultCamelContext camelContext = new OsgiDefaultCamelContext(context); >> >> The CamelContextFactory is designed as a factory bean for spring to use. >> >> Willem > -- Willem ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang |
RE: Camel under OSGi without Spring et al.
|
|
In reply to this post by Donald Whytock
Hi Don,
I wasn't able to find OsgiCamelTracker.java attached to your message. Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. -----Original Message----- From: Donald Whytock [mailto:[hidden email]] Sent: Monday, June 20, 2011 4:45 PM To: [hidden email] Subject: Re: Camel under OSGi without Spring et al. OsgiCamelTracker.java (attached) is a work in progress. There's a reference to ContextUtil; that's the service class that supplies the CamelContext singleton. Use it by subclassing it and implementing methods start() and stop(). Call setBundleContext(bundleContext) first, then startTracking(). OsgiCamelTracker.startTracking() accepts no parameters, a single String, or a Collection<String>. The strings are the names of components that you need. It'll track instances of ComponentResolver, maintaining a list of what components are available and what components are still needed. When all the components you need are available, it'll call start(); when any of the components cease to be available, it'll call stop(). If you don't supply component names, it'll react to camel-core itself becoming active, which is all you need for core components like mock, bean and file. Use routeId(<name>) in your route definitions. Use camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). Be advised, you'll need to use a singleton CamelContext if you're using SEDA queues, because SEDA queues are local to a CamelContext instance. A route that consumes from a SEDA queue from one CamelContext instance won't see anything produced to a SEDA queue from a different CamelContext instance. For OsgiDefaultCamelContext... > On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out into its own .jar so as to not worry about the Blueprint dependencies. You'll need to modify the manifest, or make your own. Don |
Re: Camel under OSGi without Spring et al.
|
|
Odd...I can see it there. I'll send it to you directly.
Don On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak <[hidden email]> wrote: > Hi Don, > > I wasn't able to find OsgiCamelTracker.java attached to your message. > > Thanks, > -Mike > > > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > -----Original Message----- > > > > From: Donald Whytock [mailto:[hidden email]] > Sent: Monday, June 20, 2011 4:45 PM > To: [hidden email] > Subject: Re: Camel under OSGi without Spring et al. > > OsgiCamelTracker.java (attached) is a work in progress. There's a > reference to ContextUtil; that's the service class that supplies the > CamelContext singleton. > > Use it by subclassing it and implementing methods start() and stop(). > Call setBundleContext(bundleContext) first, then startTracking(). > > OsgiCamelTracker.startTracking() accepts no parameters, a single > String, or a Collection<String>. The strings are the names of > components that you need. It'll track instances of ComponentResolver, > maintaining a list of what components are available and what > components are still needed. When all the components you need are > available, it'll call start(); when any of the components cease to be > available, it'll call stop(). > > If you don't supply component names, it'll react to camel-core itself > becoming active, which is all you need for core components like mock, > bean and file. > > Use routeId(<name>) in your route definitions. Use > camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use > camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). > > Be advised, you'll need to use a singleton CamelContext if you're > using SEDA queues, because SEDA queues are local to a CamelContext > instance. A route that consumes from a SEDA queue from one > CamelContext instance won't see anything produced to a SEDA queue from > a different CamelContext instance. > > For OsgiDefaultCamelContext... > >> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >>> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. > > org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out > into its own .jar so as to not worry about the Blueprint dependencies. > You'll need to modify the manifest, or make your own. > > Don > > |
Re: Camel under OSGi without Spring et al.
|
The ASF mailinglists tend to strip of attachments...
Bye, Norman 2011/6/21 Donald Whytock <[hidden email]>: > Odd...I can see it there. I'll send it to you directly. > > Don > > On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak <[hidden email]> wrote: >> Hi Don, >> >> I wasn't able to find OsgiCamelTracker.java attached to your message. >> >> Thanks, >> -Mike >> >> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> -----Original Message----- >> >> >> >> From: Donald Whytock [mailto:[hidden email]] >> Sent: Monday, June 20, 2011 4:45 PM >> To: [hidden email] >> Subject: Re: Camel under OSGi without Spring et al. >> >> OsgiCamelTracker.java (attached) is a work in progress. There's a >> reference to ContextUtil; that's the service class that supplies the >> CamelContext singleton. >> >> Use it by subclassing it and implementing methods start() and stop(). >> Call setBundleContext(bundleContext) first, then startTracking(). >> >> OsgiCamelTracker.startTracking() accepts no parameters, a single >> String, or a Collection<String>. The strings are the names of >> components that you need. It'll track instances of ComponentResolver, >> maintaining a list of what components are available and what >> components are still needed. When all the components you need are >> available, it'll call start(); when any of the components cease to be >> available, it'll call stop(). >> >> If you don't supply component names, it'll react to camel-core itself >> becoming active, which is all you need for core components like mock, >> bean and file. >> >> Use routeId(<name>) in your route definitions. Use >> camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use >> camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). >> >> Be advised, you'll need to use a singleton CamelContext if you're >> using SEDA queues, because SEDA queues are local to a CamelContext >> instance. A route that consumes from a SEDA queue from one >> CamelContext instance won't see anything produced to a SEDA queue from >> a different CamelContext instance. >> >> For OsgiDefaultCamelContext... >> >>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >>>> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. >> >> org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out >> into its own .jar so as to not worry about the Blueprint dependencies. >> You'll need to modify the manifest, or make your own. >> >> Don >> >> > |
Re: Camel under OSGi without Spring et al.
Administrator
|
In reply to this post by Donald Whytock
L.S.,
I think adding support for pure OSGi deployments (no blueprint, spring, ...) might be an interesting addition to Camel as such. It's probably not that useful in the environment we typically have in mind (ESB, enterprise applications, ...) but for other use cases it may make perfect sense to be able to have a more lightweight approach available as well. Not entirely sure what the current OsgiCamelTracker is doing, but we could e.g. (just guessing what would be useful here, so feel free to amend/comment/...) build something that tracks RouteBuilder instances in the OSGi Service Registry and then creates CamelContexts to run those, with a service property to allow configuring the CamelContext instance to add the routes to? Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Jun 21, 2011 at 4:38 PM, Donald Whytock <[hidden email]> wrote: > Odd...I can see it there. I'll send it to you directly. > > Don > > On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak <[hidden email]> wrote: >> Hi Don, >> >> I wasn't able to find OsgiCamelTracker.java attached to your message. >> >> Thanks, >> -Mike >> >> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> -----Original Message----- >> >> >> >> From: Donald Whytock [mailto:[hidden email]] >> Sent: Monday, June 20, 2011 4:45 PM >> To: [hidden email] >> Subject: Re: Camel under OSGi without Spring et al. >> >> OsgiCamelTracker.java (attached) is a work in progress. There's a >> reference to ContextUtil; that's the service class that supplies the >> CamelContext singleton. >> >> Use it by subclassing it and implementing methods start() and stop(). >> Call setBundleContext(bundleContext) first, then startTracking(). >> >> OsgiCamelTracker.startTracking() accepts no parameters, a single >> String, or a Collection<String>. The strings are the names of >> components that you need. It'll track instances of ComponentResolver, >> maintaining a list of what components are available and what >> components are still needed. When all the components you need are >> available, it'll call start(); when any of the components cease to be >> available, it'll call stop(). >> >> If you don't supply component names, it'll react to camel-core itself >> becoming active, which is all you need for core components like mock, >> bean and file. >> >> Use routeId(<name>) in your route definitions. Use >> camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use >> camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). >> >> Be advised, you'll need to use a singleton CamelContext if you're >> using SEDA queues, because SEDA queues are local to a CamelContext >> instance. A route that consumes from a SEDA queue from one >> CamelContext instance won't see anything produced to a SEDA queue from >> a different CamelContext instance. >> >> For OsgiDefaultCamelContext... >> >>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >>>> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. >> >> org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out >> into its own .jar so as to not worry about the Blueprint dependencies. >> You'll need to modify the manifest, or make your own. >> >> Don >> >> >
Regards,
Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ |
RE: Camel under OSGi without Spring et al.
|
|
Hi Gert,
I'm clearly only one user (and a seriously new one, at that), but you've captured exactly how I would like to use Camel. If I can provide use/test cases, or feedback about my limited environment I'd be happy to do so. Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. -----Original Message----- From: Gert Vanthienen [mailto:[hidden email]] Sent: Tuesday, June 21, 2011 10:59 AM To: [hidden email] Subject: Re: Camel under OSGi without Spring et al. L.S., I think adding support for pure OSGi deployments (no blueprint, spring, ...) might be an interesting addition to Camel as such. It's probably not that useful in the environment we typically have in mind (ESB, enterprise applications, ...) but for other use cases it may make perfect sense to be able to have a more lightweight approach available as well. Not entirely sure what the current OsgiCamelTracker is doing, but we could e.g. (just guessing what would be useful here, so feel free to amend/comment/...) build something that tracks RouteBuilder instances in the OSGi Service Registry and then creates CamelContexts to run those, with a service property to allow configuring the CamelContext instance to add the routes to? Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Jun 21, 2011 at 4:38 PM, Donald Whytock <[hidden email]> wrote: > Odd...I can see it there. I'll send it to you directly. > > Don > > On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak <[hidden email]> wrote: >> Hi Don, >> >> I wasn't able to find OsgiCamelTracker.java attached to your message. >> >> Thanks, >> -Mike >> >> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> -----Original Message----- >> >> >> >> From: Donald Whytock [mailto:[hidden email]] >> Sent: Monday, June 20, 2011 4:45 PM >> To: [hidden email] >> Subject: Re: Camel under OSGi without Spring et al. >> >> OsgiCamelTracker.java (attached) is a work in progress. There's a >> reference to ContextUtil; that's the service class that supplies the >> CamelContext singleton. >> >> Use it by subclassing it and implementing methods start() and stop(). >> Call setBundleContext(bundleContext) first, then startTracking(). >> >> OsgiCamelTracker.startTracking() accepts no parameters, a single >> String, or a Collection<String>. The strings are the names of >> components that you need. It'll track instances of ComponentResolver, >> maintaining a list of what components are available and what >> components are still needed. When all the components you need are >> available, it'll call start(); when any of the components cease to be >> available, it'll call stop(). >> >> If you don't supply component names, it'll react to camel-core itself >> becoming active, which is all you need for core components like mock, >> bean and file. >> >> Use routeId(<name>) in your route definitions. Use >> camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use >> camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). >> >> Be advised, you'll need to use a singleton CamelContext if you're >> using SEDA queues, because SEDA queues are local to a CamelContext >> instance. A route that consumes from a SEDA queue from one >> CamelContext instance won't see anything produced to a SEDA queue from >> a different CamelContext instance. >> >> For OsgiDefaultCamelContext... >> >>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >>>> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. >> >> org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out >> into its own .jar so as to not worry about the Blueprint dependencies. >> You'll need to modify the manifest, or make your own. >> >> Don >> >> > |
RE: Camel under OSGi without Spring et al.
|
|
In reply to this post by Donald Whytock
Hi Don,
I reviewed your sample code. Thanks very much for sharing that with me. If I understand the intent and explanation correctly, you are using your OsgiCamelTracker to delay the start-up of your Camel-using code until you can be sure that the requisite ComponentResolver services have become available. In my current project we use OSGi Declarative Services, so I have set up an OSGi component (yay, overloaded terms!) that requests a service reference for a ComponentResolver that can provide the Camel 'file' component. This should have the same effect of delaying the activation of my CamelStarter class until that service can be bound. Here's the DS xml: <?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="com.cra.camelsandbox.CamelStarter"> <implementation class="com.cra.camelsandbox.CamelStarter"/> <reference bind="bindComponentResolver" cardinality="1..1" interface="org.apache.camel.spi.ComponentResolver" name="ComponentResolver" policy="dynamic" target="(component=file)" unbind="unbindComponentResolver"/> </scr:component> And the Java class itself: public class CamelStarter { private static final transient Logger LOG = LoggerFactory.getLogger(CamelStarter.class); protected void activate(ComponentContext context) throws Exception { LOG.trace("activating"); CamelContext camelContext = new OsgiDefaultCamelContext(context.getBundleContext()); // camelContext.start(); } protected void deactivate(ComponentContext context) { LOG.trace("deactivating"); } protected void bindComponentResolver(ComponentResolver cr) { LOG.trace("Binding ComponentResolver"); // Ignored, since the ComponentResolver is not directly used } protected void unbindComponentResolver(ComponentResolver cr) { LOG.trace("Unbinding ComponentResolver"); // Ignored, since the ComponentResolver is not directly used } } With the third line of the activate method commented out, everything seems to go as planned: [21 Jun 2011 15:08:19] TRACE [Component Resolve Thread (Bundle 12)] CamelStarter - Binding ComponentResolver [21 Jun 2011 15:08:19] TRACE [Component Resolve Thread (Bundle 12)] CamelStarter - activating But if I uncomment it, I get this: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) Caused by: org.apache.camel.RuntimeCamelException: Error staring OSGiTypeConverter due: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206) at org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164) at org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) at org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) at org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613) at org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899) at org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984) at org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001) at org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940) at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314) at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18) ... 15 more Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] at org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79) at org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395) at org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202) ... 37 more Root exception: org.apache.camel.RuntimeCamelException: Error staring OSGiTypeConverter due: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206) at org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164) at org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) at org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) at org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613) at org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899) at org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984) at org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001) at org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940) at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314) at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] at org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79) at org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395) at org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202) ... 37 more Slightly off topic, your advice about needing to share the CamelContext object as a singleton (wrt. SEDA, etc.) was received loud and clear. What you see here is me just trying to keep my test cases simple for now. So that's where I am stuck at the moment. I'm sorry not to be working more directly from your sample code, but please correct me if its service management strategy/intent is different from my understanding. Does my current problem make sense? What am I missing? Thanks, -Mike THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. -----Original Message----- From: Donald Whytock [mailto:[hidden email]] Sent: Monday, June 20, 2011 4:45 PM To: [hidden email] Subject: Re: Camel under OSGi without Spring et al. OsgiCamelTracker.java (attached) is a work in progress. There's a reference to ContextUtil; that's the service class that supplies the CamelContext singleton. Use it by subclassing it and implementing methods start() and stop(). Call setBundleContext(bundleContext) first, then startTracking(). OsgiCamelTracker.startTracking() accepts no parameters, a single String, or a Collection<String>. The strings are the names of components that you need. It'll track instances of ComponentResolver, maintaining a list of what components are available and what components are still needed. When all the components you need are available, it'll call start(); when any of the components cease to be available, it'll call stop(). If you don't supply component names, it'll react to camel-core itself becoming active, which is all you need for core components like mock, bean and file. Use routeId(<name>) in your route definitions. Use camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). Be advised, you'll need to use a singleton CamelContext if you're using SEDA queues, because SEDA queues are local to a CamelContext instance. A route that consumes from a SEDA queue from one CamelContext instance won't see anything produced to a SEDA queue from a different CamelContext instance. For OsgiDefaultCamelContext... > On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out into its own .jar so as to not worry about the Blueprint dependencies. You'll need to modify the manifest, or make your own. Don |
Re: Camel under OSGi without Spring et al.
|
|
Not familiar with OSGi Declarative Services, so there will be some
guesswork on my part... Yes, I use OsgiCamelTracker to control the Camel-using bundles. But it also tracks whether the CamelContext-singleton-providing service (ContextUtil) is up. That service in turn depends on an instance of org.apache.camel.spi.TypeConverterLoader service. camel-core has a BundleActivator. That activator starts a BundleTracker that checks every bundle that launches (including itself) to see if it contains components that need to be loaded. It registers the components as services first, then it registers TypeConverterLoader. From the example you gave, it looks like you need to create another class that binds to TypeConverterLoader, generates and starts a CamelContext, and then registers itself as a service; then your CamelStarter class would bind to that service along with the ComponentResolver(s), and fetch the CamelContext from that service. Can you bind to multiple services via your XML, such that your class won't activate until all the other services are found? Don On Tue, Jun 21, 2011 at 3:21 PM, Michael Furtak <[hidden email]> wrote: > Hi Don, > > I reviewed your sample code. Thanks very much for sharing that with me. If I understand the intent and explanation correctly, you are using your OsgiCamelTracker to delay the start-up of your Camel-using code until you can be sure that the requisite ComponentResolver services have become available. > > In my current project we use OSGi Declarative Services, so I have set up an OSGi component (yay, overloaded terms!) that requests a service reference for a ComponentResolver that can provide the Camel 'file' component. This should have the same effect of delaying the activation of my CamelStarter class until that service can be bound. Here's the DS xml: > > <?xml version="1.0" encoding="UTF-8"?> > <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="com.cra.camelsandbox.CamelStarter"> > <implementation class="com.cra.camelsandbox.CamelStarter"/> > <reference bind="bindComponentResolver" cardinality="1..1" interface="org.apache.camel.spi.ComponentResolver" name="ComponentResolver" policy="dynamic" target="(component=file)" unbind="unbindComponentResolver"/> > </scr:component> > > > And the Java class itself: > > public class CamelStarter > { > private static final transient Logger LOG = LoggerFactory.getLogger(CamelStarter.class); > > protected void activate(ComponentContext context) throws Exception > { > LOG.trace("activating"); > CamelContext camelContext = new OsgiDefaultCamelContext(context.getBundleContext()); > // camelContext.start(); > } > > protected void deactivate(ComponentContext context) > { > LOG.trace("deactivating"); > } > > protected void bindComponentResolver(ComponentResolver cr) > { > LOG.trace("Binding ComponentResolver"); > // Ignored, since the ComponentResolver is not directly used > } > > protected void unbindComponentResolver(ComponentResolver cr) > { > LOG.trace("Unbinding ComponentResolver"); > // Ignored, since the ComponentResolver is not directly used > } > } > > With the third line of the activate method commented out, everything seems to go as planned: > > [21 Jun 2011 15:08:19] TRACE [Component Resolve Thread (Bundle 12)] CamelStarter - Binding ComponentResolver > [21 Jun 2011 15:08:19] TRACE [Component Resolve Thread (Bundle 12)] CamelStarter - activating > > > But if I uncomment it, I get this: > > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) > at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) > at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339) > at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588) > at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) > at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441) > at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) > at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) > at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) > at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) > at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) > Caused by: org.apache.camel.RuntimeCamelException: Error staring OSGiTypeConverter due: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206) > at org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164) > at org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69) > at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) > at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) > at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) > at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) > at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) > at org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) > at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) > at org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613) > at org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899) > at org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984) > at org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001) > at org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940) > at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423) > at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) > at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314) > at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18) > ... 15 more > Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > at org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79) > at org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395) > at org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) > at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) > at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202) > ... 37 more > Root exception: > org.apache.camel.RuntimeCamelException: Error staring OSGiTypeConverter due: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206) > at org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164) > at org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69) > at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) > at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) > at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) > at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) > at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) > at org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) > at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) > at org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613) > at org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899) > at org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984) > at org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001) > at org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940) > at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423) > at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) > at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314) > at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) > at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) > at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339) > at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588) > at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) > at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441) > at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) > at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) > at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) > at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) > at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) > Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] > at org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79) > at org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395) > at org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) > at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) > at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) > at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202) > ... 37 more > > Slightly off topic, your advice about needing to share the CamelContext object as a singleton (wrt. SEDA, etc.) was received loud and clear. What you see here is me just trying to keep my test cases simple for now. > > > So that's where I am stuck at the moment. I'm sorry not to be working more directly from your sample code, but please correct me if its service management strategy/intent is different from my understanding. Does my current problem make sense? What am I missing? > > > Thanks, > -Mike > > > > > > > > > THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. > > -----Original Message----- > > > > From: Donald Whytock [mailto:[hidden email]] > Sent: Monday, June 20, 2011 4:45 PM > To: [hidden email] > Subject: Re: Camel under OSGi without Spring et al. > > OsgiCamelTracker.java (attached) is a work in progress. There's a > reference to ContextUtil; that's the service class that supplies the > CamelContext singleton. > > Use it by subclassing it and implementing methods start() and stop(). > Call setBundleContext(bundleContext) first, then startTracking(). > > OsgiCamelTracker.startTracking() accepts no parameters, a single > String, or a Collection<String>. The strings are the names of > components that you need. It'll track instances of ComponentResolver, > maintaining a list of what components are available and what > components are still needed. When all the components you need are > available, it'll call start(); when any of the components cease to be > available, it'll call stop(). > > If you don't supply component names, it'll react to camel-core itself > becoming active, which is all you need for core components like mock, > bean and file. > > Use routeId(<name>) in your route definitions. Use > camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use > camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). > > Be advised, you'll need to use a singleton CamelContext if you're > using SEDA queues, because SEDA queues are local to a CamelContext > instance. A route that consumes from a SEDA queue from one > CamelContext instance won't see anything produced to a SEDA queue from > a different CamelContext instance. > > For OsgiDefaultCamelContext... > >> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >>> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. > > org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out > into its own .jar so as to not worry about the Blueprint dependencies. > You'll need to modify the manifest, or make your own. > > Don > > |
Re: Camel under OSGi without Spring et al.
|
Administrator
|
L.S.,
I just raised https://issues.apache.org/jira/browse/CAMEL-4147 to keep track of this request. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Jun 21, 2011 at 10:09 PM, Donald Whytock <[hidden email]> wrote: > Not familiar with OSGi Declarative Services, so there will be some > guesswork on my part... > > Yes, I use OsgiCamelTracker to control the Camel-using bundles. But > it also tracks whether the CamelContext-singleton-providing service > (ContextUtil) is up. That service in turn depends on an instance of > org.apache.camel.spi.TypeConverterLoader service. > > camel-core has a BundleActivator. That activator starts a > BundleTracker that checks every bundle that launches (including > itself) to see if it contains components that need to be loaded. It > registers the components as services first, then it registers > TypeConverterLoader. > > From the example you gave, it looks like you need to create another > class that binds to TypeConverterLoader, generates and starts a > CamelContext, and then registers itself as a service; then your > CamelStarter class would bind to that service along with the > ComponentResolver(s), and fetch the CamelContext from that service. > > Can you bind to multiple services via your XML, such that your class > won't activate until all the other services are found? > > Don > > On Tue, Jun 21, 2011 at 3:21 PM, Michael Furtak <[hidden email]> wrote: >> Hi Don, >> >> I reviewed your sample code. Thanks very much for sharing that with me. If I understand the intent and explanation correctly, you are using your OsgiCamelTracker to delay the start-up of your Camel-using code until you can be sure that the requisite ComponentResolver services have become available. >> >> In my current project we use OSGi Declarative Services, so I have set up an OSGi component (yay, overloaded terms!) that requests a service reference for a ComponentResolver that can provide the Camel 'file' component. This should have the same effect of delaying the activation of my CamelStarter class until that service can be bound. Here's the DS xml: >> >> <?xml version="1.0" encoding="UTF-8"?> >> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="com.cra.camelsandbox.CamelStarter"> >> <implementation class="com.cra.camelsandbox.CamelStarter"/> >> <reference bind="bindComponentResolver" cardinality="1..1" interface="org.apache.camel.spi.ComponentResolver" name="ComponentResolver" policy="dynamic" target="(component=file)" unbind="unbindComponentResolver"/> >> </scr:component> >> >> >> And the Java class itself: >> >> public class CamelStarter >> { >> private static final transient Logger LOG = LoggerFactory.getLogger(CamelStarter.class); >> >> protected void activate(ComponentContext context) throws Exception >> { >> LOG.trace("activating"); >> CamelContext camelContext = new OsgiDefaultCamelContext(context.getBundleContext()); >> // camelContext.start(); >> } >> >> protected void deactivate(ComponentContext context) >> { >> LOG.trace("deactivating"); >> } >> >> protected void bindComponentResolver(ComponentResolver cr) >> { >> LOG.trace("Binding ComponentResolver"); >> // Ignored, since the ComponentResolver is not directly used >> } >> >> protected void unbindComponentResolver(ComponentResolver cr) >> { >> LOG.trace("Unbinding ComponentResolver"); >> // Ignored, since the ComponentResolver is not directly used >> } >> } >> >> With the third line of the activate method commented out, everything seems to go as planned: >> >> [21 Jun 2011 15:08:19] TRACE [Component Resolve Thread (Bundle 12)] CamelStarter - Binding ComponentResolver >> [21 Jun 2011 15:08:19] TRACE [Component Resolve Thread (Bundle 12)] CamelStarter - activating >> >> >> But if I uncomment it, I get this: >> >> java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) >> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) >> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339) >> at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588) >> at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) >> at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441) >> at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) >> at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) >> at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) >> at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) >> at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) >> Caused by: org.apache.camel.RuntimeCamelException: Error staring OSGiTypeConverter due: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] >> at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206) >> at org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164) >> at org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69) >> at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) >> at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) >> at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) >> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) >> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) >> at org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) >> at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) >> at org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613) >> at org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899) >> at org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984) >> at org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001) >> at org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940) >> at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423) >> at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) >> at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314) >> at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18) >> ... 15 more >> Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] >> at org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79) >> at org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395) >> at org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) >> at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) >> at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202) >> ... 37 more >> Root exception: >> org.apache.camel.RuntimeCamelException: Error staring OSGiTypeConverter due: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] >> at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206) >> at org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164) >> at org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69) >> at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) >> at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) >> at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) >> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) >> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) >> at org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) >> at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) >> at org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613) >> at org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899) >> at org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984) >> at org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001) >> at org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940) >> at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423) >> at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) >> at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314) >> at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) >> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) >> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339) >> at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588) >> at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) >> at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441) >> at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) >> at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) >> at org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767) >> at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89) >> at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70) >> Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file, org.apache.camel.component.bean, org.apache.camel.converter] >> at org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79) >> at org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395) >> at org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67) >> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54) >> at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60) >> at org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202) >> ... 37 more >> >> Slightly off topic, your advice about needing to share the CamelContext object as a singleton (wrt. SEDA, etc.) was received loud and clear. What you see here is me just trying to keep my test cases simple for now. >> >> >> So that's where I am stuck at the moment. I'm sorry not to be working more directly from your sample code, but please correct me if its service management strategy/intent is different from my understanding. Does my current problem make sense? What am I missing? >> >> >> Thanks, >> -Mike >> >> >> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. >> >> -----Original Message----- >> >> >> >> From: Donald Whytock [mailto:[hidden email]] >> Sent: Monday, June 20, 2011 4:45 PM >> To: [hidden email] >> Subject: Re: Camel under OSGi without Spring et al. >> >> OsgiCamelTracker.java (attached) is a work in progress. There's a >> reference to ContextUtil; that's the service class that supplies the >> CamelContext singleton. >> >> Use it by subclassing it and implementing methods start() and stop(). >> Call setBundleContext(bundleContext) first, then startTracking(). >> >> OsgiCamelTracker.startTracking() accepts no parameters, a single >> String, or a Collection<String>. The strings are the names of >> components that you need. It'll track instances of ComponentResolver, >> maintaining a list of what components are available and what >> components are still needed. When all the components you need are >> available, it'll call start(); when any of the components cease to be >> available, it'll call stop(). >> >> If you don't supply component names, it'll react to camel-core itself >> becoming active, which is all you need for core components like mock, >> bean and file. >> >> Use routeId(<name>) in your route definitions. Use >> camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use >> camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). >> >> Be advised, you'll need to use a singleton CamelContext if you're >> using SEDA queues, because SEDA queues are local to a CamelContext >> instance. A route that consumes from a SEDA queue from one >> CamelContext instance won't see anything produced to a SEDA queue from >> a different CamelContext instance. >> >> For OsgiDefaultCamelContext... >> >>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[hidden email]> wrote: >>>> I did come across mention of this in my troubleshooting exploration. It seems to be part of a bundle called camel-core-osgi, is that right? I don't think I have it in my 2.7.2 distribution. Is it something I need to bundle myself? I also saw mention of it being private to the Spring bundle, which is what prompted my discussion about not wanting to bring in Spring. >> >> org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out >> into its own .jar so as to not worry about the Blueprint dependencies. >> You'll need to modify the manifest, or make your own. >> >> Don >> >> >
Regards,
Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ |
«
Return to Camel - Users
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |