Hi, 2009/4/20 Clement Escoffier <clement.escoff...@gmail.com>
> Hi, > > > On 19.04.2009, at 16:45, Guillaume Nodet wrote: > > After having experimented a bit with iPojo, I came to the conclusion >> that this library is not the best suited for the blueprint spec. >> The main reason is that the way it handles a dependency on an OSGi >> service is by enhancing/instrumenting the pojo that will be injected. >> While this works very well, it is quite problematic for implementing >> the blueprint spec, as this spec clearly mandates the creation of a >> proxy that will later be injected. >> > > I definitely agree. I just read the spec (nice weekend reading :-)), and > for sure it is built on dynamic proxies. From the other side, iPOJO was made > to avoid the injection of proxies. When it's required, it uses generated > "smart" proxies (to reduce the performance cost). > What's the difference between dynamic proxy and "smart" proxy? BTW, I'm looking forward to seeing iPOJO 1.3 release. (cause of iPOJO API in trunk) I think that iPOJO components can be bound to groovy by extending groovy.lang.Binding class, and new iPOJO component can be created using iPOJO API on groovy side. =) Regards, Xeraph Yang
