You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Clement Escoffier <cl...@gmail.com> on 2009/02/03 17:03:38 UTC
Re: Thoughts on migrating from servicebinder to Declarative Services or iPojo?
Hi,
On 03.02.2009, at 16:40, Stuart McCulloch wrote:
> 2009/2/3 Rob Walker <ro...@ascert.com>
>
>> 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.
>
>
> 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.
>
>
> 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 :-).
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
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
>
>
> --
> Cheers, Stuart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Thoughts on migrating from servicebinder to Declarative Services
or iPojo?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/2/4 Clement Escoffier <cl...@gmail.com>
> Hi,
> On 03.02.2009, at 16:40, Stuart McCulloch wrote:
>
> 2009/2/3 Rob Walker <ro...@ascert.com>
>>
>> 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
>>> robw@ascert.com
>>> +44 (0)20 7488 3470
>>> www.ascert.com
>>>
>>
>> --
>> Cheers, Stuart
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Cheers, Stuart
Re: Thoughts on migrating from servicebinder to Declarative Services
or iPojo?
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
OK, Thanks for the explanation.
--G
Stuart McCulloch a écrit :
>>
>> Just to be 100% clear, does this means that your instrumented class can be
>> reused outside of OSGi ?
>> I mean,will the following pseudo code work outside of OSGi, with the
>> manipulated classes ?
>>
>> MyComponent mc = new MyComponent();
>> mc.setProperty("hello");
>> mc.doSomething();
>>
>>
>
> based on Clement's detailed description at:
>
> http://felix.apache.org/site/dive-into-the-ipojo-manipulation-depths.html
>
> the answer is yes, but there seems to be a type dependency on
> InstanceManager
> which means that (in my limited experience) you need the iPOJO bundle
> installed
> alongside your enhanced bundle to provide certain packages - this is just so
> the
> bundle resolves, it's not actually used at runtime. If you construct
> instances directly
> the iPOJO management fields default to null and the instance reverts to its
> original
> behaviour :)
>
> so yes, you can re-use the manipulated classes outside of the iPOJO
> container
> (very similar to how you can re-use Guice annotated classes in other
> containers,
> because the @Inject annotation doesn't introduce a mandatory dependency ;)
>
> Thanks
>
>> --Guillaume
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
Re: Thoughts on migrating from servicebinder to Declarative Services
or iPojo?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/2/4 Guillaume Sauthier <Gu...@objectweb.org>
> Clement Escoffier a écrit :
>
>> Hi,
>> On 03.02.2009, at 16:40, Stuart McCulloch wrote:
>>
>> 2009/2/3 Rob Walker <ro...@ascert.com>
>>>
>>> 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.
>>
>>
> Just to be 100% clear, does this means that your instrumented class can be
> reused outside of OSGi ?
> I mean,will the following pseudo code work outside of OSGi, with the
> manipulated classes ?
>
> MyComponent mc = new MyComponent();
> mc.setProperty("hello");
> mc.doSomething();
>
based on Clement's detailed description at:
http://felix.apache.org/site/dive-into-the-ipojo-manipulation-depths.html
the answer is yes, but there seems to be a type dependency on
InstanceManager
which means that (in my limited experience) you need the iPOJO bundle
installed
alongside your enhanced bundle to provide certain packages - this is just so
the
bundle resolves, it's not actually used at runtime. If you construct
instances directly
the iPOJO management fields default to null and the instance reverts to its
original
behaviour :)
so yes, you can re-use the manipulated classes outside of the iPOJO
container
(very similar to how you can re-use Guice annotated classes in other
containers,
because the @Inject annotation doesn't introduce a mandatory dependency ;)
Thanks
> --Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Cheers, Stuart
Re: Thoughts on migrating from servicebinder to Declarative Services
or iPojo?
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Feb 3, 2009 at 6:11 PM, Guillaume Sauthier
<Gu...@objectweb.org> wrote:
> Clement Escoffier a écrit :
>>
>> Hi,
>> On 03.02.2009, at 16:40, Stuart McCulloch wrote:
>>
>>> 2009/2/3 Rob Walker <ro...@ascert.com>
>>>
>>>> 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.
>>
>
> Just to be 100% clear, does this means that your instrumented class can be
> reused outside of OSGi ?
> I mean,will the following pseudo code work outside of OSGi, with the
> manipulated classes ?
>
> MyComponent mc = new MyComponent();
> mc.setProperty("hello");
> mc.doSomething();
Yes, that is possible. You would have to provide the packages needed
by the iPOJO classes (as mentioned by Stuart). However, the needed
iPOJO run time bundle is very small so that should not be an issue at
all. In case you don't even want that, all you have to do is to
include the packages inside the bundle and make the imports optional.
This way, the classes can be used with or without iPOJO installed
inside your target platform.
Personally, all I can say is that iPOJO makes OSGi development an
order of magnitude faster for me. What i like most about it is that I
can take boilerplate code and just move it into a handler. This allows
me to actually extend the framework by what I need (whatever that
might be in a given situation) in a well defined way. Being able to
create compositions is great as well. Also, given the latest
performance figures, iPOJO is just really fast and lightweight plus
it doesn't depend on java 1.5 (even though it supports annotations) --
hence, can be used in all environments. Definitely have a look at
richard slides (http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf).
regards,
Karl
> Thanks
> --Guillaume
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Thoughts on migrating from servicebinder to Declarative Services
or iPojo?
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Clement Escoffier a écrit :
> Hi,
> On 03.02.2009, at 16:40, Stuart McCulloch wrote:
>
>> 2009/2/3 Rob Walker <ro...@ascert.com>
>>
>>> 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.
>
Just to be 100% clear, does this means that your instrumented class can
be reused outside of OSGi ?
I mean,will the following pseudo code work outside of OSGi, with the
manipulated classes ?
MyComponent mc = new MyComponent();
mc.setProperty("hello");
mc.doSomething();
Thanks
--Guillaume