I certainly don't share Camel routes between bundles on an interface or implementation somehow and I do use OSGi services when appropriate. Just not as much as I used to. I'm aware of the trade offs.
One such trade off is by using Camel routes I can move a bundle from one instance running on one machine and put it on another one and simply switch the substitution variables in the cfg from something like direct-vm to activemq or what have you. Using CXF and a recipient list to fire requests to bundles is a very decoupled as the bundles don't depend on each other, don't inject interfaces into one another and don't require proxies and are ambivalent to start up order. Decoupled is a matter of perspective. I don't have bundles hanging waiting for dependencies. No hung proxies or other problems. Easy to use the EIPs for what they are intended to do, easy to switch from sync to async mode, etc. When the bundles don't have physical dependencies on interface/services being injected into them it is easy to move and modify and hot load without concern. Are there trade-offs? Of course. You have to manage the endpoint definitions. On Fuse I don't think shared properties are permitted in Blueprint. . On Friday, August 11, 2017 at 6:40:36 AM UTC-5, Christian Schneider wrote: > > I agree. Not using services in OSGi is a bad idea. Services allow you to > keep your bundles loosely coupled. > You should also try to only use standard java types in your service > interfaces. > > I have seen some cases where people share camel routes between bundles or > use camel classes in service interfaces. In the start this seems fun but as > your system grows you realize that the coupling badly hurts your ability to > evolve parts of your system. > > Also when using services try to avoid retrieving a service and blocking > until it is there. Instead let DS or another DI framework inject the > service. Especially using DS this will make your system highly reactive to > changes and even work when things are replaced at runtime like in > development. It also copes well with refreshes like they happen a lot in > apache karaf when you install features. > > Christian > > 2017-08-11 9:51 GMT+02:00 'Christoph Läubrich' via OPS4J < > [email protected] <javascript:>>: > >> Well in fact here is no framework that solves all your problems... I'm >> using OSGi and DS for year now and it works without a problem, even though >> there where sometimes bugs in the code or flaws in my concepts or >> architectural decsions I had to solve. But I never exspected that DS, OSGi >> or anything else "solves" this for me in a magical way. >> >> If you want to use OSGi DS is IMO the best choice (as mentioned before) >> because it provides what we have with bundles and import/exports to the >> service level, but must be used with OSGi in mind. The problem is that ppl >> exspect the can just throw things togeter and it would then work in some >> magical way. >> >> >> You can add Blueprint, CDI, Camel and whatever to the mix try to keep >> away OSGi but will be hurt by "flaky" things then. Thats not the fault of >> the framework/lib but a restriction of the programming model. I can't find >> "use of services ends up being complex" but the other way round: Using >> services with DS is incredible easy and powerfull. So if you have a >> problem, provide an example and I'm sure you will get help to solve the >> problem. >> >> Also DS can of course be used to wire up "things" inside your bundle, >> what should keep you away of doing so? >> >> Am 10.08.2017 22:37, schrieb [email protected] <javascript:>: >> >>> I did use it not too long ago but had to get back to a paying gig. But >>> the technology is certainly what we need, I think. >>> >>> SCR is fine until you then realize that you have wire things up in your >>> bundle and don't have too many good choices about the matter. Blueprint is >>> a little long tooth and clunky to work with. From what I've heard from >>> Christian and others it sounds as though the proxies have naughty habits. I >>> can say that with time I've drifted away from using OSGi services when I >>> have a reasonable choice between using a service and something like a Camel >>> route. A lot of that has to do with the path of least resistance. I'm >>> putting in a system right now that has a data source bootstrapped via PAX >>> JDBC which is then consumed by a "connector" bundle (essentially a DTO). >>> Initially I'd exported that connector as a service for other bundles to >>> pick up and make service calls. But the services seemed to have flaky >>> problems when I uninstalled/installed. Since I had other issues to solve I >>> just fell back to using Camel routes for data access from other bundles. >>> >>> That doesn't seem to be a unique situation for me with Blueprint. Maybe >>> it isn't Blueprint. But the use of services ends up being complex and >>> that's a shame. If there's a technology like CDI that lets me easily export >>> and reference service that will be spectacular. I was stunned about how >>> easy is to test with the CDI anotations. >>> >>> Of course, for bread and butter I'm still consulting on Fuse and that's >>> not exactly cutting edge.... >>> >>> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] <javascript:> >> >> --- You received this message because you are subscribed to the Google >> Groups "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
