2009/2/4 Clement Escoffier <[email protected]> > Hi, > On 03.02.2009, at 16:40, Stuart McCulloch wrote: > > 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 >> > > The instrumentation is made in a way that you don't need iPOJO to use a > manipulated class (see > http://felix.apache.org/site/dive-into-the-ipojo-manipulation-depths.html). > The only downside, is that the iPOJO management will not happen. >
I tried the latest release and when I attempt to resolve an iPOJO enhanced bundle I get an unresolved constraint for "org.apache.felix.ipojo.architecture" which I assume is something to do with the iPOJO InstanceManager that's woven into the bytecode so I do seem to need the core iPOJO bundle before I can use my bundle :( this isn't a major issue, but it would be nice if the dependency was optional > 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!) >> > > It's on the roadmap :-). You can already do it with the iPOJO API, that is > in my sandbox right now (it will be released soon). Except that it does not > support inner classes, your class is manipulated on the fly. > excellent! > > 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) >> > > As the class is usable without iPOJO management, you can use another DI > framework. For example, iPOJO components supports JML and aspectJ weaving. > > 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 >> > > iPOJO provides features to implement your own "handler" (i.e. piece of > container). So, you could implement your own registry or implement a handler > interacting with Eclipse extensions too as well :-). > cool, is support for extension points on the roadmap? ( btw, the extension registry bundles can run on Felix :) Clement > >> 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 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Cheers, Stuart
