Hello Christian, Firstly I thought about some kind of indirect dependency on camel, but I suppose that such an indirection will complicate the component with copying of headers, bodies, properties, etc. from and to a camel exchange in case of duplication of camel exchange api (lightweight analogues of camel exchanges).
The self contained interface will be provided as some kind of additional module of the component, so there will be a dependency on the component and in my opinion there is no a big difference between depending on the camel api or the camel component api. What do you think about something like a bean binding (http://camel.apache.org/bean-binding.html) from the consumer side? In that case almost any interface can be used as published OSGi service to process exchanges. Regards, Sergey > Hi Sergey, > the component looks pretty good already. There is one thing though I > would like to discuss. > More or less the core of this component is the OSGi service we use to > communicate between the bundles. You currently use the camel Processor > interface for this. > While this is quite suitable for pure camel to camel communication I > wonder if we could come up with an interface that is not tied to camel. > The Processor interfaces indirectly references a lot of the camel core > code. I wonder if we could design a simple self contained interface that > would also be reuseable for other projects to do a generic communication > with camel. > Christian > Am 22.05.2012 19:57, schrieb szh.s...@gmail.com: >> 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 >> >>
