2009/2/4 Richard S. Hall <[email protected]> > 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 >> >> 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!) >> > > The reason for this decision build-time instrumentation is because it will > work across all OSGi framework impls without requiring an containerisms. For > example, since there is no standard way to hook into OSGi class loading, it > is difficult to property set the protection domain of classes instrumented > at run time. We know this, because iPOJO started life using run-time > instrumentation. :-) Once a standard hook is available, then run-time > instrumentation is possible without any difficulty. >
no problem, perhaps there's a way to make the Import-Package constraints introduced by iPOJO optional - it sounds like they're actually optional dependencies from what Clement says... FWIW, here is the Import-Package from one of the examples: Import-Package: org.osgi.service.log;version=1.3, org.apache.felix.ipo jo.architecture;version= 1.2.0, ipojo.example.hello, org.apache.felix .ipojo;version= 1.2.0, org.osgi.service.cm;version=1.2 the original source didn't have any iPOJO, log or cm references > 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) >> >> > > I am not sure what this really means, since I think pretty much all OSGi DI > frameworks integrate through the service registry. What else you are > thinking about? > it's more about "non-service" integration, for example Guice has an integration module that can use Spring beans - it sounds like something like this could be done using handlers that delegate to Spring / Guice / whatever's needed to provide a dependency > > 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 >> > > DS would certainly be easier coming from SB, since there is lineage between > the two. > > Obviously, I am biased for iPOJO. It is written specifically for OSGi and > can offer more OSGi-specific stuff as a result, e.g., minimal metadata via > byte code inspection, automatic concurrency handling for service > dependencies, component participation in provided service lifecycle, dynamic > service properties for provided services, service scoping through > hierarchical composition, etc. Still, in iPOJO we strive to keep the simple > case simple. (See the presentation on our wiki for some simple examples.) > > However, I imagine the best way to figure it out is to create some examples > in the various technologies. > yep, preferably open-source so everyone can benefit ;) > -> richard > > 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 >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Cheers, Stuart
