On Thu, Jun 18, 2009 at 4:45 AM, Dmitry Skavish<skav...@gmail.com> wrote: > On Mon, Jun 15, 2009 at 10:13 AM, Todor Boev <t.b...@prosyst.bg> wrote: > >> Dmitry Skavish wrote: >> >>> Hello all, >>> I am trying to understand the differences between those technologies, but >>> I >>> could not find any article which compares all them side by side. >>> Can somebody summarize pros and cons or point me to page where this is >>> already done? >>> >>> We are using Guice, so I guess the logical way is to use peaberry, but I >>> don't want to make a decision without knowing all the differences. >>> >>> I guess I am somewhat confused about iPOJO and DS because they look to me >>> strikingly similar. What is the main difference between them? >>> >>> Thanks a lot! >>> >>> >> Here's a descent comparison between Spring DM, OSGi DS and iPojo. >> >> >> http://www.slideshare.net/heiko.seeberger/jax-09-osgi-service-components-models >> >> Generally speaking iPojo seems to be OSGi DS but done right...and than >> evolved to an ever more different pluggable animal :) If I had to choose I >> would pick iPojo over OSGi DS. > > > Unfortunately we can't do bytecode manipulations, so iPOJO is out of the > question. And I am not really happy with all this iPOJO magic with private > fields.
iPOJO does the manipulation at packaging time (think of it as another compiler). There is an online manipulator as well but for the general case all you need is to run this compiler one time over your jar and thats it then. So I don't think its out of the question because of that. Not much I can do about the magic ... However, keep in mind that all the dependency injection stuff must do some kind of "magic" (at least in terms of reflection etc.). Depending on what your target platform looks like iPOJO's benefit is that it introduces a very low size penalty (much less then all the others) and is really fast specifically because of not using reflection. regards, Karl > I can't find comparisons between Peaberry and the rest so I'll try to make a >> brief one here: >> >> Peaberry is a transparent integration between a random dynamic service >> registry and Guice. So just like Guice it has no explicit component model, >> component lifecycle, component configuration. You have the usual Guice >> free-form, constructor oriented DI plus @Named injection points for static >> configuration. The two things I find I am missing in Peaberry are special >> support for dynamic configuration (e.g. the OSGi ConfigurationAdmin service) >> and automatic activation/deactivation of my bundles. Of these the >> activation/deactivation issue seems the easier one to solve: you code a >> BundleActivator that follows a standard pattern. In fact I am working right >> now on a small extender that will capture the pattern once and for all. >> Doing dynamic configuration by hand requires a bit more work (e.g. must >> synchronize properly). You can check my thoughts on the problems here: >> >> http://code.google.com/p/peaberry/wiki/ConfigRegistry >> >> I guess in the end it comes down to the style of DI you want to use. If you >> want a more free-form, constructor injection - go with Guice. If you want a >> component-oriented approach go with iPojo or Spring DM. I would not go with >> OSGi DS since it does not really do much to shield you from the service >> dynamics. > > > So by "it does not really do much to shield you from the service dynamics" > you meant I have to do all those synchronizations (in DS) everywhere or > something else? > > -- > Dmitry Skavish > -- Karl Pauls karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
