You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/04/28 13:11:22 UTC
Camel startup dependencies in OSGI/Karaf
I'm using Karaf to deploy my Camel routes. However, I run into
problems during startup due to dependency ordering. Some of these
ordering problems are OSGI/Karaf specific and have nothing to do with
Camel. I've discussed them on the Felix user mailing list and I have
workarounds for that. The Camel problems remain though.
When trying to deploy both my routes and the camel bundles in Karaf,
my routes fail to iniitialize because the referenced camel component
("file:" in this case) is not registered in Camel yet. I've tried to
solve this with workarounds in Karaf. It is possible but not very
elegant at all.
Guillaume Nodet (via users@felix.apache.org) suggested to me that this
is more of a Camel problem than a Karaf problem. In his opinion (and
mine), it would be much better if Camel published components using
OSGI services. That way my services could have a service dependency on
the Camel services so that my service would start when the Camel
service was available. As I understand it, today Camel just scans
bundles as they are started and updates its component registry. This
makes it impossible for dependent bundles (like my routes) to know
whether all the required prerequisites are in place before starting
the route.
If components were published using a component specific interface, I
could add a service dependency to that service and wait until it
becomes available before trying to start my routes.
Has anyone else had similar issues?What is the recommended workaround?
Are there any plans for improvement?
/Bengt
Re: Camel startup dependencies in OSGI/Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
Perfect!
2010/5/5 Guillaume Nodet <gn...@gmail.com>:
> I've created https://issues.apache.org/activemq/browse/CAMEL-2693 for that.
>
> On Thu, Apr 29, 2010 at 14:06, Bengt Rodehav <be...@rodehav.com> wrote:
>
>> Hello Willem,
>>
>> Yeah, I guess it could potentially be a lot of service dependencies.
>> Remember though that these dependencies are present regardless if we
>> handle them or not. If I have routes referring to 10 components, then
>> these components MUST be registered before I create my routes. Right?
>>
>> Today, there is no way of being informed when necessary registrations
>> have been done in Camel. This means that one has to make sure, by
>> other means, that every bundle that could potentially contain a
>> required camel component must be resolved and started before trying to
>> use those components. This is not an easy task in OSGI. Sure, I would
>> like Karaf to be able to set startlevels per feature as a way to
>> handle bundles that are not properly OSGI'ified. But I think that
>> Camel is such a great integration platform that I want it to be
>> properly OSGI'ified without having to rely on container specific
>> features.
>>
>> In OSGI, it is common practice to be well aware of you service
>> dependencies and handle them. Sometimes this is complex - yes - but it
>> is still done.
>>
>> /Bengt
>>
>>
>> 2010/4/29 Willem Jiang <wi...@gmail.com>:
>> > Bengt Rodehav wrote:
>> >>
>> >> This is exactly the way I was thinking:
>> >>
>> >> - Define a new interface representing a Camel component ( e g
>> >> CamelComponentService)
>> >> - Use a service property to identify the specific componente (e g
>> >> "camel.component")
>> >>
>> >> This enables me to wait for a service with that specific service
>> >> property to be available. E g in my case I'm using iPOJO to
>> >> instantiate OSGI service and can use an annotation similar to the
>> >> following:
>> >>
>> >> @Requires(filter={camel.component=file})
>> >> private CamelComponentService fileComponent;
>> >
>> > Yeah, it's much clear for me.
>> > But if your camel route have to deal with more than ten camel components,
>> > does it necessary to list all the dependencies with the iPOJO annotation?
>> >
>> > Willem
>> >
>> >>
>> >> I didn't check that I used the right syntax above. However, the result
>> >> is that my service will not be started until a CamelComponentService
>> >> with the service property "camel.component" with the value "file" has
>> >> been started. I think this would be very useful. It gives Camel a way
>> >> to publish the availability of components to the outside world - and
>> >> also a way to do it the OSGI way.
>> >>
>> >> /Bengt
>> >>
>> >>
>> >> 2010/4/29 Guillaume Nodet <gn...@gmail.com>:
>> >>>
>> >>> We don't have to add anything to the component jars I think. It should
>> >>> be
>> >>> possible to extend camel-osgi bundle in the following way:
>> >>> * when a bundle containing a component is started, register a service
>> in
>> >>> the osgi registry for the component. I think it should be a new
>> >>> interface
>> >>> which will allow the creation of components (a component factory)
>> >>> registered with an asssociated property to identify the type of
>> component
>> >>> (file, jms, etc...)
>> >>> * modify the osgi component resolver or camel context go to the
>> registry
>> >>> and wait for some time until all the components are available
>> >>> The last part might be a bit more tricky, as we need to find a good
>> >>> strategy
>> >>> for that. It could also be configurable on the osgi component context
>> to
>> >>> some degree.
>> >>>
>> >>> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Bengt Rodehav wrote:
>> >>>>
>> >>>>> Thanks for your reply Willem,
>> >>>>>
>> >>>>> I will try to the bundle dependency of camel-core to my route bundle
>> >>>>> as you suggested - sounds like good advice.
>> >>>>>
>> >>>>> I wasn't sure what you mean by your last paragraph:
>> >>>>>
>> >>>>> If you need to dependent on some specify component interface will
>> >>>>>>
>> >>>>>> introduce
>> >>>>>> the OSGi related dependency to the camel components.
>> >>>>>> We need to find another way to do it.
>> >>>>>>
>> >>>>> I assume that there was a problem with my suggestion but I didn't
>> >>>>> quite understand what.
>> >>>>>
>> >>>> Oh, that is if you want to publish the camel components into a OSGi
>> >>>> service, you can do it in the BundleActivator, or write some XML
>> >>>> configuration to leverage Spring DM or Blue Print to do it.
>> >>>>
>> >>>> If you are using BundleActivator, you will introduce some kind of
>> >>>> compile
>> >>>> time dependency of OSGi jar. As we also want camel components work
>> well
>> >>>> as a
>> >>>> stand alone Java application, we should avoid introduce this kind of
>> >>>> dependency.
>> >>>>
>> >>>> Maybe the xml configuration is a choice for us.
>> >>>>
>> >>>> This solution need to your start the Spring-DM or BluePrint container
>> >>>> before your camel route bundle to let the container lookup the bundle
>> >>>> context for the xml configuration. It seems we are back to your
>> original
>> >>>> question. And if you start the camel components bundles before you
>> start
>> >>>> up
>> >>>> your camel route bundle, you will not hit this kind of issue.
>> >>>>
>> >>>> Willem
>> >>>>
>> >>>>
>> >>>>
>> >>>>> /Bengt
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>> >>>>>
>> >>>>>> Hi
>> >>>>>>
>> >>>>>> Please see my comments in the mail.
>> >>>>>>
>> >>>>>> Bengt Rodehav wrote:
>> >>>>>>
>> >>>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>> >>>>>>> problems during startup due to dependency ordering. Some of these
>> >>>>>>> ordering problems are OSGI/Karaf specific and have nothing to do
>> with
>> >>>>>>> Camel. I've discussed them on the Felix user mailing list and I
>> have
>> >>>>>>> workarounds for that. The Camel problems remain though.
>> >>>>>>>
>> >>>>>>> When trying to deploy both my routes and the camel bundles in
>> Karaf,
>> >>>>>>> my routes fail to iniitialize because the referenced camel
>> component
>> >>>>>>> ("file:" in this case) is not registered in Camel yet. I've tried
>> to
>> >>>>>>> solve this with workarounds in Karaf. It is possible but not very
>> >>>>>>> elegant at all.
>> >>>>>>>
>> >>>>>> Can you add the bundle dependency of camel-core to your route
>> bundle?
>> >>>>>>
>> >>>>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that
>> >>>>>>> this
>> >>>>>>> is more of a Camel problem than a Karaf problem. In his opinion
>> (and
>> >>>>>>> mine), it would be much better if Camel published components using
>> >>>>>>> OSGI services. That way my services could have a service dependency
>> >>>>>>> on
>> >>>>>>> the Camel services so that my service would start when the Camel
>> >>>>>>> service was available. As I understand it, today Camel just scans
>> >>>>>>> bundles as they are started and updates its component registry.
>> This
>> >>>>>>> makes it impossible for dependent bundles (like my routes) to know
>> >>>>>>> whether all the required prerequisites are in place before starting
>> >>>>>>> the route.
>> >>>>>>>
>> >>>>>> That could be a solution of your issue.
>> >>>>>>
>> >>>>>>> If components were published using a component specific interface,
>> I
>> >>>>>>> could add a service dependency to that service and wait until it
>> >>>>>>> becomes available before trying to start my routes.
>> >>>>>>>
>> >>>>>>> If you need to dependent on some specify component interface will
>> >>>>>>
>> >>>>>> introduce
>> >>>>>> the OSGi related dependency to the camel components.
>> >>>>>> We need to find another way to do it.
>> >>>>>>
>> >>>>>> Has anyone else had similar issues?What is the recommended
>> >>>>>> workaround?
>> >>>>>>>
>> >>>>>>> Are there any plans for improvement?
>> >>>>>>>
>> >>>>>>> /Bengt
>> >>>>>>>
>> >>>>>>>
>> >>>>>> Willem
>> >>>>>>
>> >>>>>>
>> >>>
>> >>> --
>> >>> Cheers,
>> >>> Guillaume Nodet
>> >>> ------------------------
>> >>> Blog: http://gnodet.blogspot.com/
>> >>> ------------------------
>> >>> Open Source SOA
>> >>> http://fusesource.com
>> >>>
>> >>
>> >
>> >
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Guillaume Nodet <gn...@gmail.com>.
I've created https://issues.apache.org/activemq/browse/CAMEL-2693 for that.
On Thu, Apr 29, 2010 at 14:06, Bengt Rodehav <be...@rodehav.com> wrote:
> Hello Willem,
>
> Yeah, I guess it could potentially be a lot of service dependencies.
> Remember though that these dependencies are present regardless if we
> handle them or not. If I have routes referring to 10 components, then
> these components MUST be registered before I create my routes. Right?
>
> Today, there is no way of being informed when necessary registrations
> have been done in Camel. This means that one has to make sure, by
> other means, that every bundle that could potentially contain a
> required camel component must be resolved and started before trying to
> use those components. This is not an easy task in OSGI. Sure, I would
> like Karaf to be able to set startlevels per feature as a way to
> handle bundles that are not properly OSGI'ified. But I think that
> Camel is such a great integration platform that I want it to be
> properly OSGI'ified without having to rely on container specific
> features.
>
> In OSGI, it is common practice to be well aware of you service
> dependencies and handle them. Sometimes this is complex - yes - but it
> is still done.
>
> /Bengt
>
>
> 2010/4/29 Willem Jiang <wi...@gmail.com>:
> > Bengt Rodehav wrote:
> >>
> >> This is exactly the way I was thinking:
> >>
> >> - Define a new interface representing a Camel component ( e g
> >> CamelComponentService)
> >> - Use a service property to identify the specific componente (e g
> >> "camel.component")
> >>
> >> This enables me to wait for a service with that specific service
> >> property to be available. E g in my case I'm using iPOJO to
> >> instantiate OSGI service and can use an annotation similar to the
> >> following:
> >>
> >> @Requires(filter={camel.component=file})
> >> private CamelComponentService fileComponent;
> >
> > Yeah, it's much clear for me.
> > But if your camel route have to deal with more than ten camel components,
> > does it necessary to list all the dependencies with the iPOJO annotation?
> >
> > Willem
> >
> >>
> >> I didn't check that I used the right syntax above. However, the result
> >> is that my service will not be started until a CamelComponentService
> >> with the service property "camel.component" with the value "file" has
> >> been started. I think this would be very useful. It gives Camel a way
> >> to publish the availability of components to the outside world - and
> >> also a way to do it the OSGI way.
> >>
> >> /Bengt
> >>
> >>
> >> 2010/4/29 Guillaume Nodet <gn...@gmail.com>:
> >>>
> >>> We don't have to add anything to the component jars I think. It should
> >>> be
> >>> possible to extend camel-osgi bundle in the following way:
> >>> * when a bundle containing a component is started, register a service
> in
> >>> the osgi registry for the component. I think it should be a new
> >>> interface
> >>> which will allow the creation of components (a component factory)
> >>> registered with an asssociated property to identify the type of
> component
> >>> (file, jms, etc...)
> >>> * modify the osgi component resolver or camel context go to the
> registry
> >>> and wait for some time until all the components are available
> >>> The last part might be a bit more tricky, as we need to find a good
> >>> strategy
> >>> for that. It could also be configurable on the osgi component context
> to
> >>> some degree.
> >>>
> >>> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com>
> >>> wrote:
> >>>
> >>>> Bengt Rodehav wrote:
> >>>>
> >>>>> Thanks for your reply Willem,
> >>>>>
> >>>>> I will try to the bundle dependency of camel-core to my route bundle
> >>>>> as you suggested - sounds like good advice.
> >>>>>
> >>>>> I wasn't sure what you mean by your last paragraph:
> >>>>>
> >>>>> If you need to dependent on some specify component interface will
> >>>>>>
> >>>>>> introduce
> >>>>>> the OSGi related dependency to the camel components.
> >>>>>> We need to find another way to do it.
> >>>>>>
> >>>>> I assume that there was a problem with my suggestion but I didn't
> >>>>> quite understand what.
> >>>>>
> >>>> Oh, that is if you want to publish the camel components into a OSGi
> >>>> service, you can do it in the BundleActivator, or write some XML
> >>>> configuration to leverage Spring DM or Blue Print to do it.
> >>>>
> >>>> If you are using BundleActivator, you will introduce some kind of
> >>>> compile
> >>>> time dependency of OSGi jar. As we also want camel components work
> well
> >>>> as a
> >>>> stand alone Java application, we should avoid introduce this kind of
> >>>> dependency.
> >>>>
> >>>> Maybe the xml configuration is a choice for us.
> >>>>
> >>>> This solution need to your start the Spring-DM or BluePrint container
> >>>> before your camel route bundle to let the container lookup the bundle
> >>>> context for the xml configuration. It seems we are back to your
> original
> >>>> question. And if you start the camel components bundles before you
> start
> >>>> up
> >>>> your camel route bundle, you will not hit this kind of issue.
> >>>>
> >>>> Willem
> >>>>
> >>>>
> >>>>
> >>>>> /Bengt
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
> >>>>>
> >>>>>> Hi
> >>>>>>
> >>>>>> Please see my comments in the mail.
> >>>>>>
> >>>>>> Bengt Rodehav wrote:
> >>>>>>
> >>>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
> >>>>>>> problems during startup due to dependency ordering. Some of these
> >>>>>>> ordering problems are OSGI/Karaf specific and have nothing to do
> with
> >>>>>>> Camel. I've discussed them on the Felix user mailing list and I
> have
> >>>>>>> workarounds for that. The Camel problems remain though.
> >>>>>>>
> >>>>>>> When trying to deploy both my routes and the camel bundles in
> Karaf,
> >>>>>>> my routes fail to iniitialize because the referenced camel
> component
> >>>>>>> ("file:" in this case) is not registered in Camel yet. I've tried
> to
> >>>>>>> solve this with workarounds in Karaf. It is possible but not very
> >>>>>>> elegant at all.
> >>>>>>>
> >>>>>> Can you add the bundle dependency of camel-core to your route
> bundle?
> >>>>>>
> >>>>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that
> >>>>>>> this
> >>>>>>> is more of a Camel problem than a Karaf problem. In his opinion
> (and
> >>>>>>> mine), it would be much better if Camel published components using
> >>>>>>> OSGI services. That way my services could have a service dependency
> >>>>>>> on
> >>>>>>> the Camel services so that my service would start when the Camel
> >>>>>>> service was available. As I understand it, today Camel just scans
> >>>>>>> bundles as they are started and updates its component registry.
> This
> >>>>>>> makes it impossible for dependent bundles (like my routes) to know
> >>>>>>> whether all the required prerequisites are in place before starting
> >>>>>>> the route.
> >>>>>>>
> >>>>>> That could be a solution of your issue.
> >>>>>>
> >>>>>>> If components were published using a component specific interface,
> I
> >>>>>>> could add a service dependency to that service and wait until it
> >>>>>>> becomes available before trying to start my routes.
> >>>>>>>
> >>>>>>> If you need to dependent on some specify component interface will
> >>>>>>
> >>>>>> introduce
> >>>>>> the OSGi related dependency to the camel components.
> >>>>>> We need to find another way to do it.
> >>>>>>
> >>>>>> Has anyone else had similar issues?What is the recommended
> >>>>>> workaround?
> >>>>>>>
> >>>>>>> Are there any plans for improvement?
> >>>>>>>
> >>>>>>> /Bengt
> >>>>>>>
> >>>>>>>
> >>>>>> Willem
> >>>>>>
> >>>>>>
> >>>
> >>> --
> >>> Cheers,
> >>> Guillaume Nodet
> >>> ------------------------
> >>> Blog: http://gnodet.blogspot.com/
> >>> ------------------------
> >>> Open Source SOA
> >>> http://fusesource.com
> >>>
> >>
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel startup dependencies in OSGI/Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
Hello Willem,
Yeah, I guess it could potentially be a lot of service dependencies.
Remember though that these dependencies are present regardless if we
handle them or not. If I have routes referring to 10 components, then
these components MUST be registered before I create my routes. Right?
Today, there is no way of being informed when necessary registrations
have been done in Camel. This means that one has to make sure, by
other means, that every bundle that could potentially contain a
required camel component must be resolved and started before trying to
use those components. This is not an easy task in OSGI. Sure, I would
like Karaf to be able to set startlevels per feature as a way to
handle bundles that are not properly OSGI'ified. But I think that
Camel is such a great integration platform that I want it to be
properly OSGI'ified without having to rely on container specific
features.
In OSGI, it is common practice to be well aware of you service
dependencies and handle them. Sometimes this is complex - yes - but it
is still done.
/Bengt
2010/4/29 Willem Jiang <wi...@gmail.com>:
> Bengt Rodehav wrote:
>>
>> This is exactly the way I was thinking:
>>
>> - Define a new interface representing a Camel component ( e g
>> CamelComponentService)
>> - Use a service property to identify the specific componente (e g
>> "camel.component")
>>
>> This enables me to wait for a service with that specific service
>> property to be available. E g in my case I'm using iPOJO to
>> instantiate OSGI service and can use an annotation similar to the
>> following:
>>
>> @Requires(filter={camel.component=file})
>> private CamelComponentService fileComponent;
>
> Yeah, it's much clear for me.
> But if your camel route have to deal with more than ten camel components,
> does it necessary to list all the dependencies with the iPOJO annotation?
>
> Willem
>
>>
>> I didn't check that I used the right syntax above. However, the result
>> is that my service will not be started until a CamelComponentService
>> with the service property "camel.component" with the value "file" has
>> been started. I think this would be very useful. It gives Camel a way
>> to publish the availability of components to the outside world - and
>> also a way to do it the OSGI way.
>>
>> /Bengt
>>
>>
>> 2010/4/29 Guillaume Nodet <gn...@gmail.com>:
>>>
>>> We don't have to add anything to the component jars I think. It should
>>> be
>>> possible to extend camel-osgi bundle in the following way:
>>> * when a bundle containing a component is started, register a service in
>>> the osgi registry for the component. I think it should be a new
>>> interface
>>> which will allow the creation of components (a component factory)
>>> registered with an asssociated property to identify the type of component
>>> (file, jms, etc...)
>>> * modify the osgi component resolver or camel context go to the registry
>>> and wait for some time until all the components are available
>>> The last part might be a bit more tricky, as we need to find a good
>>> strategy
>>> for that. It could also be configurable on the osgi component context to
>>> some degree.
>>>
>>> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com>
>>> wrote:
>>>
>>>> Bengt Rodehav wrote:
>>>>
>>>>> Thanks for your reply Willem,
>>>>>
>>>>> I will try to the bundle dependency of camel-core to my route bundle
>>>>> as you suggested - sounds like good advice.
>>>>>
>>>>> I wasn't sure what you mean by your last paragraph:
>>>>>
>>>>> If you need to dependent on some specify component interface will
>>>>>>
>>>>>> introduce
>>>>>> the OSGi related dependency to the camel components.
>>>>>> We need to find another way to do it.
>>>>>>
>>>>> I assume that there was a problem with my suggestion but I didn't
>>>>> quite understand what.
>>>>>
>>>> Oh, that is if you want to publish the camel components into a OSGi
>>>> service, you can do it in the BundleActivator, or write some XML
>>>> configuration to leverage Spring DM or Blue Print to do it.
>>>>
>>>> If you are using BundleActivator, you will introduce some kind of
>>>> compile
>>>> time dependency of OSGi jar. As we also want camel components work well
>>>> as a
>>>> stand alone Java application, we should avoid introduce this kind of
>>>> dependency.
>>>>
>>>> Maybe the xml configuration is a choice for us.
>>>>
>>>> This solution need to your start the Spring-DM or BluePrint container
>>>> before your camel route bundle to let the container lookup the bundle
>>>> context for the xml configuration. It seems we are back to your original
>>>> question. And if you start the camel components bundles before you start
>>>> up
>>>> your camel route bundle, you will not hit this kind of issue.
>>>>
>>>> Willem
>>>>
>>>>
>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>>>
>>>>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Please see my comments in the mail.
>>>>>>
>>>>>> Bengt Rodehav wrote:
>>>>>>
>>>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>>>>> problems during startup due to dependency ordering. Some of these
>>>>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>>>>> workarounds for that. The Camel problems remain though.
>>>>>>>
>>>>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>>>>> my routes fail to iniitialize because the referenced camel component
>>>>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>>>>> solve this with workarounds in Karaf. It is possible but not very
>>>>>>> elegant at all.
>>>>>>>
>>>>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>>>>
>>>>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that
>>>>>>> this
>>>>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>>>>> mine), it would be much better if Camel published components using
>>>>>>> OSGI services. That way my services could have a service dependency
>>>>>>> on
>>>>>>> the Camel services so that my service would start when the Camel
>>>>>>> service was available. As I understand it, today Camel just scans
>>>>>>> bundles as they are started and updates its component registry. This
>>>>>>> makes it impossible for dependent bundles (like my routes) to know
>>>>>>> whether all the required prerequisites are in place before starting
>>>>>>> the route.
>>>>>>>
>>>>>> That could be a solution of your issue.
>>>>>>
>>>>>>> If components were published using a component specific interface, I
>>>>>>> could add a service dependency to that service and wait until it
>>>>>>> becomes available before trying to start my routes.
>>>>>>>
>>>>>>> If you need to dependent on some specify component interface will
>>>>>>
>>>>>> introduce
>>>>>> the OSGi related dependency to the camel components.
>>>>>> We need to find another way to do it.
>>>>>>
>>>>>> Has anyone else had similar issues?What is the recommended
>>>>>> workaround?
>>>>>>>
>>>>>>> Are there any plans for improvement?
>>>>>>>
>>>>>>> /Bengt
>>>>>>>
>>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Willem Jiang <wi...@gmail.com>.
Bengt Rodehav wrote:
> This is exactly the way I was thinking:
>
> - Define a new interface representing a Camel component ( e g
> CamelComponentService)
> - Use a service property to identify the specific componente (e g
> "camel.component")
>
> This enables me to wait for a service with that specific service
> property to be available. E g in my case I'm using iPOJO to
> instantiate OSGI service and can use an annotation similar to the
> following:
>
> @Requires(filter={camel.component=file})
> private CamelComponentService fileComponent;
Yeah, it's much clear for me.
But if your camel route have to deal with more than ten camel
components, does it necessary to list all the dependencies with the
iPOJO annotation?
Willem
>
> I didn't check that I used the right syntax above. However, the result
> is that my service will not be started until a CamelComponentService
> with the service property "camel.component" with the value "file" has
> been started. I think this would be very useful. It gives Camel a way
> to publish the availability of components to the outside world - and
> also a way to do it the OSGI way.
>
> /Bengt
>
>
> 2010/4/29 Guillaume Nodet <gn...@gmail.com>:
>> We don't have to add anything to the component jars I think. It should be
>> possible to extend camel-osgi bundle in the following way:
>> * when a bundle containing a component is started, register a service in
>> the osgi registry for the component. I think it should be a new interface
>> which will allow the creation of components (a component factory)
>> registered with an asssociated property to identify the type of component
>> (file, jms, etc...)
>> * modify the osgi component resolver or camel context go to the registry
>> and wait for some time until all the components are available
>> The last part might be a bit more tricky, as we need to find a good strategy
>> for that. It could also be configurable on the osgi component context to
>> some degree.
>>
>> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com> wrote:
>>
>>> Bengt Rodehav wrote:
>>>
>>>> Thanks for your reply Willem,
>>>>
>>>> I will try to the bundle dependency of camel-core to my route bundle
>>>> as you suggested - sounds like good advice.
>>>>
>>>> I wasn't sure what you mean by your last paragraph:
>>>>
>>>> If you need to dependent on some specify component interface will
>>>>> introduce
>>>>> the OSGi related dependency to the camel components.
>>>>> We need to find another way to do it.
>>>>>
>>>> I assume that there was a problem with my suggestion but I didn't
>>>> quite understand what.
>>>>
>>> Oh, that is if you want to publish the camel components into a OSGi
>>> service, you can do it in the BundleActivator, or write some XML
>>> configuration to leverage Spring DM or Blue Print to do it.
>>>
>>> If you are using BundleActivator, you will introduce some kind of compile
>>> time dependency of OSGi jar. As we also want camel components work well as a
>>> stand alone Java application, we should avoid introduce this kind of
>>> dependency.
>>>
>>> Maybe the xml configuration is a choice for us.
>>>
>>> This solution need to your start the Spring-DM or BluePrint container
>>> before your camel route bundle to let the container lookup the bundle
>>> context for the xml configuration. It seems we are back to your original
>>> question. And if you start the camel components bundles before you start up
>>> your camel route bundle, you will not hit this kind of issue.
>>>
>>> Willem
>>>
>>>
>>>
>>>> /Bengt
>>>>
>>>>
>>>>
>>>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>>>>
>>>>> Hi
>>>>>
>>>>> Please see my comments in the mail.
>>>>>
>>>>> Bengt Rodehav wrote:
>>>>>
>>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>>>> problems during startup due to dependency ordering. Some of these
>>>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>>>> workarounds for that. The Camel problems remain though.
>>>>>>
>>>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>>>> my routes fail to iniitialize because the referenced camel component
>>>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>>>> solve this with workarounds in Karaf. It is possible but not very
>>>>>> elegant at all.
>>>>>>
>>>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>>>
>>>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>>>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>>>> mine), it would be much better if Camel published components using
>>>>>> OSGI services. That way my services could have a service dependency on
>>>>>> the Camel services so that my service would start when the Camel
>>>>>> service was available. As I understand it, today Camel just scans
>>>>>> bundles as they are started and updates its component registry. This
>>>>>> makes it impossible for dependent bundles (like my routes) to know
>>>>>> whether all the required prerequisites are in place before starting
>>>>>> the route.
>>>>>>
>>>>> That could be a solution of your issue.
>>>>>
>>>>>> If components were published using a component specific interface, I
>>>>>> could add a service dependency to that service and wait until it
>>>>>> becomes available before trying to start my routes.
>>>>>>
>>>>>> If you need to dependent on some specify component interface will
>>>>> introduce
>>>>> the OSGi related dependency to the camel components.
>>>>> We need to find another way to do it.
>>>>>
>>>>> Has anyone else had similar issues?What is the recommended workaround?
>>>>>> Are there any plans for improvement?
>>>>>>
>>>>>> /Bengt
>>>>>>
>>>>>>
>>>>> Willem
>>>>>
>>>>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
This is exactly the way I was thinking:
- Define a new interface representing a Camel component ( e g
CamelComponentService)
- Use a service property to identify the specific componente (e g
"camel.component")
This enables me to wait for a service with that specific service
property to be available. E g in my case I'm using iPOJO to
instantiate OSGI service and can use an annotation similar to the
following:
@Requires(filter={camel.component=file})
private CamelComponentService fileComponent;
I didn't check that I used the right syntax above. However, the result
is that my service will not be started until a CamelComponentService
with the service property "camel.component" with the value "file" has
been started. I think this would be very useful. It gives Camel a way
to publish the availability of components to the outside world - and
also a way to do it the OSGI way.
/Bengt
2010/4/29 Guillaume Nodet <gn...@gmail.com>:
> We don't have to add anything to the component jars I think. It should be
> possible to extend camel-osgi bundle in the following way:
> * when a bundle containing a component is started, register a service in
> the osgi registry for the component. I think it should be a new interface
> which will allow the creation of components (a component factory)
> registered with an asssociated property to identify the type of component
> (file, jms, etc...)
> * modify the osgi component resolver or camel context go to the registry
> and wait for some time until all the components are available
> The last part might be a bit more tricky, as we need to find a good strategy
> for that. It could also be configurable on the osgi component context to
> some degree.
>
> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com> wrote:
>
>> Bengt Rodehav wrote:
>>
>>> Thanks for your reply Willem,
>>>
>>> I will try to the bundle dependency of camel-core to my route bundle
>>> as you suggested - sounds like good advice.
>>>
>>> I wasn't sure what you mean by your last paragraph:
>>>
>>> If you need to dependent on some specify component interface will
>>>> introduce
>>>> the OSGi related dependency to the camel components.
>>>> We need to find another way to do it.
>>>>
>>>
>>> I assume that there was a problem with my suggestion but I didn't
>>> quite understand what.
>>>
>>
>> Oh, that is if you want to publish the camel components into a OSGi
>> service, you can do it in the BundleActivator, or write some XML
>> configuration to leverage Spring DM or Blue Print to do it.
>>
>> If you are using BundleActivator, you will introduce some kind of compile
>> time dependency of OSGi jar. As we also want camel components work well as a
>> stand alone Java application, we should avoid introduce this kind of
>> dependency.
>>
>> Maybe the xml configuration is a choice for us.
>>
>> This solution need to your start the Spring-DM or BluePrint container
>> before your camel route bundle to let the container lookup the bundle
>> context for the xml configuration. It seems we are back to your original
>> question. And if you start the camel components bundles before you start up
>> your camel route bundle, you will not hit this kind of issue.
>>
>> Willem
>>
>>
>>
>>> /Bengt
>>>
>>>
>>>
>>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> Please see my comments in the mail.
>>>>
>>>> Bengt Rodehav wrote:
>>>>
>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>>> problems during startup due to dependency ordering. Some of these
>>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>>> workarounds for that. The Camel problems remain though.
>>>>>
>>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>>> my routes fail to iniitialize because the referenced camel component
>>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>>> solve this with workarounds in Karaf. It is possible but not very
>>>>> elegant at all.
>>>>>
>>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>>
>>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>>> mine), it would be much better if Camel published components using
>>>>> OSGI services. That way my services could have a service dependency on
>>>>> the Camel services so that my service would start when the Camel
>>>>> service was available. As I understand it, today Camel just scans
>>>>> bundles as they are started and updates its component registry. This
>>>>> makes it impossible for dependent bundles (like my routes) to know
>>>>> whether all the required prerequisites are in place before starting
>>>>> the route.
>>>>>
>>>> That could be a solution of your issue.
>>>>
>>>>> If components were published using a component specific interface, I
>>>>> could add a service dependency to that service and wait until it
>>>>> becomes available before trying to start my routes.
>>>>>
>>>>> If you need to dependent on some specify component interface will
>>>> introduce
>>>> the OSGi related dependency to the camel components.
>>>> We need to find another way to do it.
>>>>
>>>> Has anyone else had similar issues?What is the recommended workaround?
>>>>> Are there any plans for improvement?
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>> Willem
>>>>
>>>>
>>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Willem Jiang <wi...@gmail.com>.
Guillaume Nodet wrote:
> We don't have to add anything to the component jars I think. It should be
> possible to extend camel-osgi bundle in the following way:
> * when a bundle containing a component is started, register a service in
> the osgi registry for the component. I think it should be a new interface
> which will allow the creation of components (a component factory)
> registered with an asssociated property to identify the type of component
> (file, jms, etc...)
> * modify the osgi component resolver or camel context go to the registry
> and wait for some time until all the components are available
> The last part might be a bit more tricky, as we need to find a good strategy
> for that. It could also be configurable on the osgi component context to
> some degree.
CamelContext will try to get the component which the schema ID, and we
can override this behavior in camel-osgi to check if the component
service is available.
My question is current we are leverage Spring DM to manage the Camel
route context life cycle. If I block the thread which call the starting
the camel context from the Spring DM, does it will have some side effect
on the Spring DM thread ? And Do I need to manage the camel context life
cycle by myself in camel ?
Willem
>
> On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com> wrote:
>
>> Bengt Rodehav wrote:
>>
>>> Thanks for your reply Willem,
>>>
>>> I will try to the bundle dependency of camel-core to my route bundle
>>> as you suggested - sounds like good advice.
>>>
>>> I wasn't sure what you mean by your last paragraph:
>>>
>>> If you need to dependent on some specify component interface will
>>>> introduce
>>>> the OSGi related dependency to the camel components.
>>>> We need to find another way to do it.
>>>>
>>> I assume that there was a problem with my suggestion but I didn't
>>> quite understand what.
>>>
>> Oh, that is if you want to publish the camel components into a OSGi
>> service, you can do it in the BundleActivator, or write some XML
>> configuration to leverage Spring DM or Blue Print to do it.
>>
>> If you are using BundleActivator, you will introduce some kind of compile
>> time dependency of OSGi jar. As we also want camel components work well as a
>> stand alone Java application, we should avoid introduce this kind of
>> dependency.
>>
>> Maybe the xml configuration is a choice for us.
>>
>> This solution need to your start the Spring-DM or BluePrint container
>> before your camel route bundle to let the container lookup the bundle
>> context for the xml configuration. It seems we are back to your original
>> question. And if you start the camel components bundles before you start up
>> your camel route bundle, you will not hit this kind of issue.
>>
>> Willem
>>
>>
>>
>>> /Bengt
>>>
>>>
>>>
>>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> Please see my comments in the mail.
>>>>
>>>> Bengt Rodehav wrote:
>>>>
>>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>>> problems during startup due to dependency ordering. Some of these
>>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>>> workarounds for that. The Camel problems remain though.
>>>>>
>>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>>> my routes fail to iniitialize because the referenced camel component
>>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>>> solve this with workarounds in Karaf. It is possible but not very
>>>>> elegant at all.
>>>>>
>>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>>
>>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>>> mine), it would be much better if Camel published components using
>>>>> OSGI services. That way my services could have a service dependency on
>>>>> the Camel services so that my service would start when the Camel
>>>>> service was available. As I understand it, today Camel just scans
>>>>> bundles as they are started and updates its component registry. This
>>>>> makes it impossible for dependent bundles (like my routes) to know
>>>>> whether all the required prerequisites are in place before starting
>>>>> the route.
>>>>>
>>>> That could be a solution of your issue.
>>>>
>>>>> If components were published using a component specific interface, I
>>>>> could add a service dependency to that service and wait until it
>>>>> becomes available before trying to start my routes.
>>>>>
>>>>> If you need to dependent on some specify component interface will
>>>> introduce
>>>> the OSGi related dependency to the camel components.
>>>> We need to find another way to do it.
>>>>
>>>> Has anyone else had similar issues?What is the recommended workaround?
>>>>> Are there any plans for improvement?
>>>>>
>>>>> /Bengt
>>>>>
>>>>>
>>>> Willem
>>>>
>>>>
>
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Guillaume Nodet <gn...@gmail.com>.
We don't have to add anything to the component jars I think. It should be
possible to extend camel-osgi bundle in the following way:
* when a bundle containing a component is started, register a service in
the osgi registry for the component. I think it should be a new interface
which will allow the creation of components (a component factory)
registered with an asssociated property to identify the type of component
(file, jms, etc...)
* modify the osgi component resolver or camel context go to the registry
and wait for some time until all the components are available
The last part might be a bit more tricky, as we need to find a good strategy
for that. It could also be configurable on the osgi component context to
some degree.
On Thu, Apr 29, 2010 at 04:30, Willem Jiang <wi...@gmail.com> wrote:
> Bengt Rodehav wrote:
>
>> Thanks for your reply Willem,
>>
>> I will try to the bundle dependency of camel-core to my route bundle
>> as you suggested - sounds like good advice.
>>
>> I wasn't sure what you mean by your last paragraph:
>>
>> If you need to dependent on some specify component interface will
>>> introduce
>>> the OSGi related dependency to the camel components.
>>> We need to find another way to do it.
>>>
>>
>> I assume that there was a problem with my suggestion but I didn't
>> quite understand what.
>>
>
> Oh, that is if you want to publish the camel components into a OSGi
> service, you can do it in the BundleActivator, or write some XML
> configuration to leverage Spring DM or Blue Print to do it.
>
> If you are using BundleActivator, you will introduce some kind of compile
> time dependency of OSGi jar. As we also want camel components work well as a
> stand alone Java application, we should avoid introduce this kind of
> dependency.
>
> Maybe the xml configuration is a choice for us.
>
> This solution need to your start the Spring-DM or BluePrint container
> before your camel route bundle to let the container lookup the bundle
> context for the xml configuration. It seems we are back to your original
> question. And if you start the camel components bundles before you start up
> your camel route bundle, you will not hit this kind of issue.
>
> Willem
>
>
>
>> /Bengt
>>
>>
>>
>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>>
>>> Hi
>>>
>>> Please see my comments in the mail.
>>>
>>> Bengt Rodehav wrote:
>>>
>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>> problems during startup due to dependency ordering. Some of these
>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>> workarounds for that. The Camel problems remain though.
>>>>
>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>> my routes fail to iniitialize because the referenced camel component
>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>> solve this with workarounds in Karaf. It is possible but not very
>>>> elegant at all.
>>>>
>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>
>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>> mine), it would be much better if Camel published components using
>>>> OSGI services. That way my services could have a service dependency on
>>>> the Camel services so that my service would start when the Camel
>>>> service was available. As I understand it, today Camel just scans
>>>> bundles as they are started and updates its component registry. This
>>>> makes it impossible for dependent bundles (like my routes) to know
>>>> whether all the required prerequisites are in place before starting
>>>> the route.
>>>>
>>> That could be a solution of your issue.
>>>
>>>> If components were published using a component specific interface, I
>>>> could add a service dependency to that service and wait until it
>>>> becomes available before trying to start my routes.
>>>>
>>>> If you need to dependent on some specify component interface will
>>> introduce
>>> the OSGi related dependency to the camel components.
>>> We need to find another way to do it.
>>>
>>> Has anyone else had similar issues?What is the recommended workaround?
>>>> Are there any plans for improvement?
>>>>
>>>> /Bengt
>>>>
>>>>
>>> Willem
>>>
>>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel startup dependencies in OSGI/Karaf
Posted by Willem Jiang <wi...@gmail.com>.
Bengt Rodehav wrote:
> Thanks for your reply Willem,
>
> I will try to the bundle dependency of camel-core to my route bundle
> as you suggested - sounds like good advice.
>
> I wasn't sure what you mean by your last paragraph:
>
>> If you need to dependent on some specify component interface will introduce
>> the OSGi related dependency to the camel components.
>> We need to find another way to do it.
>
> I assume that there was a problem with my suggestion but I didn't
> quite understand what.
Oh, that is if you want to publish the camel components into a OSGi
service, you can do it in the BundleActivator, or write some XML
configuration to leverage Spring DM or Blue Print to do it.
If you are using BundleActivator, you will introduce some kind of
compile time dependency of OSGi jar. As we also want camel components
work well as a stand alone Java application, we should avoid introduce
this kind of dependency.
Maybe the xml configuration is a choice for us.
This solution need to your start the Spring-DM or BluePrint container
before your camel route bundle to let the container lookup the bundle
context for the xml configuration. It seems we are back to your original
question. And if you start the camel components bundles before you start
up your camel route bundle, you will not hit this kind of issue.
Willem
>
> /Bengt
>
>
>
> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>> Hi
>>
>> Please see my comments in the mail.
>>
>> Bengt Rodehav wrote:
>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>> problems during startup due to dependency ordering. Some of these
>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>> Camel. I've discussed them on the Felix user mailing list and I have
>>> workarounds for that. The Camel problems remain though.
>>>
>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>> my routes fail to iniitialize because the referenced camel component
>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>> solve this with workarounds in Karaf. It is possible but not very
>>> elegant at all.
>> Can you add the bundle dependency of camel-core to your route bundle?
>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>> mine), it would be much better if Camel published components using
>>> OSGI services. That way my services could have a service dependency on
>>> the Camel services so that my service would start when the Camel
>>> service was available. As I understand it, today Camel just scans
>>> bundles as they are started and updates its component registry. This
>>> makes it impossible for dependent bundles (like my routes) to know
>>> whether all the required prerequisites are in place before starting
>>> the route.
>> That could be a solution of your issue.
>>> If components were published using a component specific interface, I
>>> could add a service dependency to that service and wait until it
>>> becomes available before trying to start my routes.
>>>
>> If you need to dependent on some specify component interface will introduce
>> the OSGi related dependency to the camel components.
>> We need to find another way to do it.
>>
>>> Has anyone else had similar issues?What is the recommended workaround?
>>> Are there any plans for improvement?
>>>
>>> /Bengt
>>>
>>
>> Willem
>>
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Willem Jiang <wi...@gmail.com>.
Guillaume Nodet wrote:
> On Wed, Apr 28, 2010 at 17:30, Bengt Rodehav <be...@rodehav.com> wrote:
>
>> Thanks for your reply Willem,
>>
>> I will try to the bundle dependency of camel-core to my route bundle
>> as you suggested - sounds like good advice.
>>
>
> This won't work I think. The reason is that a camel component will only be
> used
> if the bundle containing the component is started. However, there is no way
> to
> express such a dependency on a "started" bundle in OSGi. Adding a bundle
> dependency will only ensure the bundle is resolved.
>
Sorry, it's my bad, I missed the bundle dependency with the OSGi service
dependencies.
Willem
>
>> I wasn't sure what you mean by your last paragraph:
>>
>>> If you need to dependent on some specify component interface will
>> introduce
>>> the OSGi related dependency to the camel components.
>>> We need to find another way to do it.
>> I assume that there was a problem with my suggestion but I didn't
>> quite understand what.
>>
>> /Bengt
>>
>>
>>
>> 2010/4/28 Willem Jiang <wi...@gmail.com>:
>>> Hi
>>>
>>> Please see my comments in the mail.
>>>
>>> Bengt Rodehav wrote:
>>>> I'm using Karaf to deploy my Camel routes. However, I run into
>>>> problems during startup due to dependency ordering. Some of these
>>>> ordering problems are OSGI/Karaf specific and have nothing to do with
>>>> Camel. I've discussed them on the Felix user mailing list and I have
>>>> workarounds for that. The Camel problems remain though.
>>>>
>>>> When trying to deploy both my routes and the camel bundles in Karaf,
>>>> my routes fail to iniitialize because the referenced camel component
>>>> ("file:" in this case) is not registered in Camel yet. I've tried to
>>>> solve this with workarounds in Karaf. It is possible but not very
>>>> elegant at all.
>>> Can you add the bundle dependency of camel-core to your route bundle?
>>>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>>>> is more of a Camel problem than a Karaf problem. In his opinion (and
>>>> mine), it would be much better if Camel published components using
>>>> OSGI services. That way my services could have a service dependency on
>>>> the Camel services so that my service would start when the Camel
>>>> service was available. As I understand it, today Camel just scans
>>>> bundles as they are started and updates its component registry. This
>>>> makes it impossible for dependent bundles (like my routes) to know
>>>> whether all the required prerequisites are in place before starting
>>>> the route.
>>> That could be a solution of your issue.
>>>> If components were published using a component specific interface, I
>>>> could add a service dependency to that service and wait until it
>>>> becomes available before trying to start my routes.
>>>>
>>> If you need to dependent on some specify component interface will
>> introduce
>>> the OSGi related dependency to the camel components.
>>> We need to find another way to do it.
>>>
>>>> Has anyone else had similar issues?What is the recommended workaround?
>>>> Are there any plans for improvement?
>>>>
>>>> /Bengt
>>>>
>>>
>>> Willem
>>>
>
>
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Apr 28, 2010 at 17:30, Bengt Rodehav <be...@rodehav.com> wrote:
> Thanks for your reply Willem,
>
> I will try to the bundle dependency of camel-core to my route bundle
> as you suggested - sounds like good advice.
>
This won't work I think. The reason is that a camel component will only be
used
if the bundle containing the component is started. However, there is no way
to
express such a dependency on a "started" bundle in OSGi. Adding a bundle
dependency will only ensure the bundle is resolved.
>
> I wasn't sure what you mean by your last paragraph:
>
> > If you need to dependent on some specify component interface will
> introduce
> > the OSGi related dependency to the camel components.
> > We need to find another way to do it.
>
> I assume that there was a problem with my suggestion but I didn't
> quite understand what.
>
> /Bengt
>
>
>
> 2010/4/28 Willem Jiang <wi...@gmail.com>:
> > Hi
> >
> > Please see my comments in the mail.
> >
> > Bengt Rodehav wrote:
> >>
> >> I'm using Karaf to deploy my Camel routes. However, I run into
> >> problems during startup due to dependency ordering. Some of these
> >> ordering problems are OSGI/Karaf specific and have nothing to do with
> >> Camel. I've discussed them on the Felix user mailing list and I have
> >> workarounds for that. The Camel problems remain though.
> >>
> >> When trying to deploy both my routes and the camel bundles in Karaf,
> >> my routes fail to iniitialize because the referenced camel component
> >> ("file:" in this case) is not registered in Camel yet. I've tried to
> >> solve this with workarounds in Karaf. It is possible but not very
> >> elegant at all.
> >
> > Can you add the bundle dependency of camel-core to your route bundle?
> >>
> >> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
> >> is more of a Camel problem than a Karaf problem. In his opinion (and
> >> mine), it would be much better if Camel published components using
> >> OSGI services. That way my services could have a service dependency on
> >> the Camel services so that my service would start when the Camel
> >> service was available. As I understand it, today Camel just scans
> >> bundles as they are started and updates its component registry. This
> >> makes it impossible for dependent bundles (like my routes) to know
> >> whether all the required prerequisites are in place before starting
> >> the route.
> >
> > That could be a solution of your issue.
> >>
> >> If components were published using a component specific interface, I
> >> could add a service dependency to that service and wait until it
> >> becomes available before trying to start my routes.
> >>
> >
> > If you need to dependent on some specify component interface will
> introduce
> > the OSGi related dependency to the camel components.
> > We need to find another way to do it.
> >
> >> Has anyone else had similar issues?What is the recommended workaround?
> >> Are there any plans for improvement?
> >>
> >> /Bengt
> >>
> >
> >
> > Willem
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel startup dependencies in OSGI/Karaf
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks for your reply Willem,
I will try to the bundle dependency of camel-core to my route bundle
as you suggested - sounds like good advice.
I wasn't sure what you mean by your last paragraph:
> If you need to dependent on some specify component interface will introduce
> the OSGi related dependency to the camel components.
> We need to find another way to do it.
I assume that there was a problem with my suggestion but I didn't
quite understand what.
/Bengt
2010/4/28 Willem Jiang <wi...@gmail.com>:
> Hi
>
> Please see my comments in the mail.
>
> Bengt Rodehav wrote:
>>
>> I'm using Karaf to deploy my Camel routes. However, I run into
>> problems during startup due to dependency ordering. Some of these
>> ordering problems are OSGI/Karaf specific and have nothing to do with
>> Camel. I've discussed them on the Felix user mailing list and I have
>> workarounds for that. The Camel problems remain though.
>>
>> When trying to deploy both my routes and the camel bundles in Karaf,
>> my routes fail to iniitialize because the referenced camel component
>> ("file:" in this case) is not registered in Camel yet. I've tried to
>> solve this with workarounds in Karaf. It is possible but not very
>> elegant at all.
>
> Can you add the bundle dependency of camel-core to your route bundle?
>>
>> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
>> is more of a Camel problem than a Karaf problem. In his opinion (and
>> mine), it would be much better if Camel published components using
>> OSGI services. That way my services could have a service dependency on
>> the Camel services so that my service would start when the Camel
>> service was available. As I understand it, today Camel just scans
>> bundles as they are started and updates its component registry. This
>> makes it impossible for dependent bundles (like my routes) to know
>> whether all the required prerequisites are in place before starting
>> the route.
>
> That could be a solution of your issue.
>>
>> If components were published using a component specific interface, I
>> could add a service dependency to that service and wait until it
>> becomes available before trying to start my routes.
>>
>
> If you need to dependent on some specify component interface will introduce
> the OSGi related dependency to the camel components.
> We need to find another way to do it.
>
>> Has anyone else had similar issues?What is the recommended workaround?
>> Are there any plans for improvement?
>>
>> /Bengt
>>
>
>
> Willem
>
Re: Camel startup dependencies in OSGI/Karaf
Posted by Willem Jiang <wi...@gmail.com>.
Hi
Please see my comments in the mail.
Bengt Rodehav wrote:
> I'm using Karaf to deploy my Camel routes. However, I run into
> problems during startup due to dependency ordering. Some of these
> ordering problems are OSGI/Karaf specific and have nothing to do with
> Camel. I've discussed them on the Felix user mailing list and I have
> workarounds for that. The Camel problems remain though.
>
> When trying to deploy both my routes and the camel bundles in Karaf,
> my routes fail to iniitialize because the referenced camel component
> ("file:" in this case) is not registered in Camel yet. I've tried to
> solve this with workarounds in Karaf. It is possible but not very
> elegant at all.
Can you add the bundle dependency of camel-core to your route bundle?
>
> Guillaume Nodet (via users@felix.apache.org) suggested to me that this
> is more of a Camel problem than a Karaf problem. In his opinion (and
> mine), it would be much better if Camel published components using
> OSGI services. That way my services could have a service dependency on
> the Camel services so that my service would start when the Camel
> service was available. As I understand it, today Camel just scans
> bundles as they are started and updates its component registry. This
> makes it impossible for dependent bundles (like my routes) to know
> whether all the required prerequisites are in place before starting
> the route.
That could be a solution of your issue.
>
> If components were published using a component specific interface, I
> could add a service dependency to that service and wait until it
> becomes available before trying to start my routes.
>
If you need to dependent on some specify component interface will
introduce the OSGi related dependency to the camel components.
We need to find another way to do it.
> Has anyone else had similar issues?What is the recommended workaround?
> Are there any plans for improvement?
>
> /Bengt
>
Willem