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 < ops4j@googlegroups.com>: > 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 r...@enjekt.org: > >> 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 - ops4j@googlegroups.com > > --- 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 ops4j+unsubscr...@googlegroups.com. > 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 - ops4j@googlegroups.com --- 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 ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
