2009/2/3 Rob Walker <[email protected]> > The servicebinder model has served us very well and still does. I note > though that there are perhaps newer approaches such as Declarative Services > and iPojo. Very interested in views on: > > * benefits of moving from servicebinder (especially any real > experiences from others who have done this) > * pros and cons of either DS or iPojo as the model to move to >
interesting, Karl and I were just chatting about this... iPOJO provides a really comprehensive component model, where you can add almost any sort of behaviour using handlers - the downside in my opinion is that it requires you to instrument your bundles in the build phase - these bundles cannot then be used without iPOJO however, as Karl rightly pointed out, when you instrument your bundle you basically make it very extendable and adaptable, so the runtime dependency on iPOJO is not that big a deal (iPOJO core is small) of course if iPOJO provided runtime instrumentation that would totally eliminate this downside (not sure if that's in the works, but it should be feasible and would be really cool, hint-hint!) another question is how well iPOJO integrates with other DI frameworks - unfortunately I haven't had time to look into this, but again it should be possible (at the very least it can interoperate via the service registry) the benefit of DS is that it's a standard that's been around the block, but the Spring DM / blueprint spec seems to have had more focus going forward. This of course doesn't mean DS is going away any time soon, as for example Eclipse/PDE is adding support for DS: http://wiki.eclipse.org/PDE/Incubator/DS you can also use the Bnd Tool or the maven-scr-plugin to generate DS metadata, minimizing the amount of XML you have to deal with. personal summary: DS is a safe choice, iPOJO requires a bit more effort to begin with but opens up a lot more possibilities in the future the most important thing to realize is that all these frameworks can co-operate via the OSGi service registry, so you can mix-n-match them and see which approach suits your application best. Most of them try not to intrude too much on component internals. will round things off with a couple of plugs: EclipseCon 2009 has a tutorial about OSGi component models ( http://www.eclipsecon.org/2009/sessions?id=245 ) Kai has a presentation of a Swing app using DS/iPOJO/etc... ( http://www.toedter.com/blog/?p=44 ) also feel free to take a peek at http://code.google.com/p/peaberry/ While it's not a component model per-se (that is being looked into) it does provide a fluent Java 5 API for injecting dynamic services. it also abstracts the registry, so in the very near future you'll be able to inject both services and Eclipse extensions (as well as your own registry if you happen to have one lying around) .. the downside of peaberry is that it requires you to use Java5 and Guice FWIW I've heard people mention they've been doing comparisons between the various component models on the Guice-OSGi group, but afaik none of these comparisons are ready for publication... HTH Any thoughts welcomed > > Regards > > -- Rob > > > Ascert - Taking systems to the Edge > [email protected] > +44 (0)20 7488 3470 > www.ascert.com > > -- Cheers, Stuart
