On 20.04.2009, at 04:23, 양봉열 wrote:
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?
The iPOJO meaning of smart proxy is a proxy generated (by using
bytecode generation) for the specific class. It avoids reflection calls.
For example when you're using iPOJO temporal dependency with proxies,
it generates a proxy delegating intercepting each method, dealing
with service availability ... The cost of such proxy is considerably
smaller than dynamic proxies.
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. =)
It will be the 1.4, and the roadmap is close to be done (at least for
this version :-)). This will contain the iPOJO API of course. My plan
is to cut a release in May.
About Groovy, sounds interesting. A hidden iPOJO feature is also the
possibility to support other component implementation types. One day,
I will document it :-)
Regards,
Clement
Regards,
Xeraph Yang
