Perfect!
2010/5/5 Guillaume Nodet <gno...@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 <willem.ji...@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 <gno...@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 <willem.ji...@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 <willem.ji...@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 us...@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 >
