Hello everybody, Thanks for considering the component.
>> osgi name is not the best name I suppose the name should be short, should prevent misunderstandings about the environment where it can be used, possibly it should describe what the component is supposed to do. Although osgi is widely-used term, it seems to be ok in the context of a camel components in my opinion. Among the possible alternatives like dynamic-service, service, osgi, osgi-service, whiteboard, osgi-whiteboard, etc., I would give the first place to osgi (for brevity) and the second - to osgi-service (for descriptiveness). If you have any other ideas of how the component should be named, please share them. Regards, Sergey > Hi guys, > I will take a look. Agree with you that osgi name is not the best name. > Thanks > Regards > JB > On 06/07/2012 09:32 AM, Claus Ibsen wrote: >> Hi >> >> We are in the process of getting Camel 2.10 done and released. >> >> Your component looks interesting but I would like more time to look >> into it, and also for the SMX / Karaf team to take a look at was, as >> its OSGi based. >> And I wonder if the scheme name of osgi is a good name, as osgi is a broad >> term? >> >> We can surely introduce this component in a patch release of 2.10 if >> there is no changes to the camel-core. >> And also at 2.11. But if all is well, then I dont see an issue to >> introduce it in 2.10.1. We have done this in the past adding new >> components to a patch release. >> >> >> >> On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitsky<szh.s...@gmail.com> >> wrote: >>> Hi Claus, >>> >>> Recently docs and integration tests of the component have been updated. >>> I suppose it's ready for now and all missing pieces and features can be >>> added later. >>> >>> >>> Regards, >>> Sergey >>> >>> >>>> On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky<szh.s...@gmail.com> >>>> wrote: >>>>> Hi Claus, >>>>> >>>>> The component can be used right now without any additions, but I'd >>>>> like to include some integration tests which will check that: >>>>> >>>>> 1. Any camel processor (even not included into the camel route) can be >>>>> published into the OSGi service registry to process exchanges. >>>>> >>>>> 2. Multiple producers can send exchanges to one/many consumers. >>>>> >>>>> Everything should work out of the box, but the samples can be rather >>>>> useful. >>>>> >>>>> Also I'd like to update docs with the samples based on the points >>>>> above. >>>>> >>>>> One more interesting thing is investigating into whether the component >>>>> can be integrated with DOSGi easily, but I suppose it can be postponed >>>>> a little bit as it's not very important, but rather useful feature. >>>>> >>> >>>> Yeah I suggest to get those pieces implemented first. >>> >>>> DOSGi can come later. >>>> For example CXF supports DOSGi, as well Fuse Fabric. >>> >>> >>> >>>>> Regards, >>>>> Sergey >>>>> >>>>>> On Tue, May 22, 2012 at 7:57 PM,<szh.s...@gmail.com> wrote: >>>>>>> Hi gurus, >>>>>>> >>>>>>> Recently I've published camel component that uses OSGi services to >>>>>>> communicate between endpoints in different bundles. >>>>>>> >>>>>>> Here is the link: https://github.com/szhem/camel-osgi >>>>>>> I've already raised JIRA issue - >>>>>>> https://issues.apache.org/jira/browse/CAMEL-5292 >>>>>>> >>>>>>> So I'd like to have some feedback if it seems to be useful. >>>>>>> >>>>>>> Regards, >>>>>>> Sergey >>>>>>> >>>>>>> >>>>> >>>>>> Sergey at first glance this seem really useful. Good work. >>>>>> Is there any missing functionality / features / tests etc? >>>>> >>> >> >> >>
