DS or iPOJO or peaberry

[Dmitry Skavish]

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!

--
Dmitry Skavish

[Todor Boev]

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.

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.

Cheers,
Todor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Skavish]

On Mon, Jun 15, 2009 at 10:13 AM, Todor Boev <t.boev@...> 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.

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]

On Thu, Jun 18, 2009 at 4:45 AM, Dmitry Skavish<skavish@...> wrote:

> On Mon, Jun 15, 2009 at 10:13 AM, Todor Boev <t.boev@...> 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
karlpauls@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Skavish]

>
> > 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

yes, I understand that, but it's some kind of a policy in my company and
there is little you can do about it.

--
Dmitry Skavish

[gnodet]

FWIW, Spring-DM is being standardized as Blueprint services.
You can find an implementation of the spec (soon to be published) at
  http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/

Blueprint is much more powerfull wrt dependency injection than DS / iPojo.
The runtime is < 300k, so it's not too eavyweight either.

On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>
> --
> Dmitry Skavish
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

On 6/18/09 10:35 AM, Guillaume Nodet wrote:
> FWIW, Spring-DM is being standardized as Blueprint services.
> You can find an implementation of the spec (soon to be published) at
>    http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>
> Blueprint is much more powerfull wrt dependency injection than DS / iPojo.
>    

I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I
can only assume you are referring to property injection, which could be
more flexible, but I cannot imagine anything else.

-> richard

> The runtime is<  300k, so it's not too eavyweight either.
>
> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>>
>> --
>> Dmitry Skavish
>>
>>      
>
>
>
>    

[gnodet]

Yeah, dependency injection, the fact that you can inject much more
things than just simple values (collections, maps, arrays.
You can also define custom converters to handle legacy code.

On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...> wrote:

> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>
>> FWIW, Spring-DM is being standardized as Blueprint services.
>> You can find an implementation of the spec (soon to be published) at
>>   http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>
>> Blueprint is much more powerfull wrt dependency injection than DS / iPojo.
>>
>
> I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I can
> only assume you are referring to property injection, which could be more
> flexible, but I cannot imagine anything else.
>
> -> richard
>
>> The runtime is<  300k, so it's not too eavyweight either.
>>
>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>>>
>>> --
>>> Dmitry Skavish
>>>
>>>
>>
>>
>>
>>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

On 6/18/09 10:56 AM, Guillaume Nodet wrote:
> Yeah, dependency injection, the fact that you can inject much more
> things than just simple values (collections, maps, arrays.
>    

This doesn't make sense to me. Dependency injection is covered by iPOJO.
Property injection is no DI, it is configuration injection, no? At a
minimum, let's try to differentiate between the two.

Are you saying collections, maps, arrays are simple values? If so, what
kind of complex values supported by BP?

-> richard

> You can also define custom converters to handle legacy code.
>
> On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...>  wrote:
>    
>> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>      
>>> FWIW, Spring-DM is being standardized as Blueprint services.
>>> You can find an implementation of the spec (soon to be published) at
>>>    http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>>
>>> Blueprint is much more powerfull wrt dependency injection than DS / iPojo.
>>>
>>>        
>> I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I can
>> only assume you are referring to property injection, which could be more
>> flexible, but I cannot imagine anything else.
>>
>> ->  richard
>>
>>      
>>> The runtime is<    300k, so it's not too eavyweight either.
>>>
>>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>>>>
>>>> --
>>>> Dmitry Skavish
>>>>
>>>>
>>>>          
>>>
>>>
>>>        
>
>
>
>    

[gnodet]

I guess what I mean is that iPojo imposes some contraints on the pojo
you build and wire together.
Whereas the goal of blueprint is to be able to wire any legacy code
without introducing any dependency on the OSGi API.
IPojo hides some of the OSGi internals but if you take a look at
http://felix.apache.org/site/white-board-pattern-handler.html, it it
tightly bound to the OSGi api imho.
I certainly did not want to start a flame war here ;-)  just to point
to another possibility.

On Thu, Jun 18, 2009 at 17:03, Richard S. Hall<heavy@...> wrote:

> On 6/18/09 10:56 AM, Guillaume Nodet wrote:
>>
>> Yeah, dependency injection, the fact that you can inject much more
>> things than just simple values (collections, maps, arrays.
>>
>
> This doesn't make sense to me. Dependency injection is covered by iPOJO.
> Property injection is no DI, it is configuration injection, no? At a
> minimum, let's try to differentiate between the two.
>
> Are you saying collections, maps, arrays are simple values? If so, what kind
> of complex values supported by BP?
>
> -> richard
>
>> You can also define custom converters to handle legacy code.
>>
>> On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...>
>>  wrote:
>>
>>>
>>> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>>
>>>>
>>>> FWIW, Spring-DM is being standardized as Blueprint services.
>>>> You can find an implementation of the spec (soon to be published) at
>>>>   http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>>>
>>>> Blueprint is much more powerfull wrt dependency injection than DS /
>>>> iPojo.
>>>>
>>>>
>>>
>>> I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I
>>> can
>>> only assume you are referring to property injection, which could be more
>>> flexible, but I cannot imagine anything else.
>>>
>>> ->  richard
>>>
>>>
>>>>
>>>> The runtime is<    300k, so it's not too eavyweight either.
>>>>
>>>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>>>>>
>>>>> --
>>>>> Dmitry Skavish
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[clement escoffier]

On 18.06.2009, at 17:18, Guillaume Nodet wrote:

> I guess what I mean is that iPojo imposes some contraints on the pojo
> you build and wire together.
> Whereas the goal of blueprint is to be able to wire any legacy code
> without introducing any dependency on the OSGi API.
> IPojo hides some of the OSGi internals but if you take a look at
> http://felix.apache.org/site/white-board-pattern-handler.html, it it
> tightly bound to the OSGi api imho.

The mentioned handler is optional. It's only used if you want to  
implement a Whiteboard pattern injecting ServiceReferences. This  
handler is not commonly used. The "regular" iPOJO powered code has no  
dependency on the OSGi API.

iPOJO injected properties limitations are:
- must have a constructor taking a String argument IF you want to use  
the configuration admin, or XML descriptors (if you're using the API,  
you can inject any type of object).
- Service Properties must be comparable (makes sense...)

Regards,

Clement

> I certainly did not want to start a flame war here ;-)  just to point
> to another possibility.
>
> On Thu, Jun 18, 2009 at 17:03, Richard S. Hall<heavy@...>  
> wrote:
>> On 6/18/09 10:56 AM, Guillaume Nodet wrote:
>>>
>>> Yeah, dependency injection, the fact that you can inject much more
>>> things than just simple values (collections, maps, arrays.
>>>
>>
>> This doesn't make sense to me. Dependency injection is covered by  
>> iPOJO.
>> Property injection is no DI, it is configuration injection, no? At a
>> minimum, let's try to differentiate between the two.
>>
>> Are you saying collections, maps, arrays are simple values? If so,  
>> what kind
>> of complex values supported by BP?
>>
>> -> richard
>>
>>> You can also define custom converters to handle legacy code.
>>>
>>> On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...>
>>>  wrote:
>>>
>>>>
>>>> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>>>
>>>>>
>>>>> FWIW, Spring-DM is being standardized as Blueprint services.
>>>>> You can find an implementation of the spec (soon to be  
>>>>> published) at
>>>>>   http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>>>>
>>>>> Blueprint is much more powerfull wrt dependency injection than  
>>>>> DS /
>>>>> iPojo.
>>>>>
>>>>>
>>>>
>>>> I'd like to hear how it is "much more powerful wrt to DI" than  
>>>> iPOJO...I
>>>> can
>>>> only assume you are referring to property injection, which could  
>>>> be more
>>>> flexible, but I cannot imagine anything else.
>>>>
>>>> ->  richard
>>>>
>>>>
>>>>>
>>>>> The runtime is<    300k, so it's not too eavyweight either.
>>>>>
>>>>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>>>>>>
>>>>>> --
>>>>>> Dmitry Skavish
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Richard S. Hall]

On 6/18/09 11:18 AM, Guillaume Nodet wrote:

> I guess what I mean is that iPojo imposes some contraints on the pojo
> you build and wire together.
> Whereas the goal of blueprint is to be able to wire any legacy code
> without introducing any dependency on the OSGi API.
> IPojo hides some of the OSGi internals but if you take a look at
> http://felix.apache.org/site/white-board-pattern-handler.html, it it
> tightly bound to the OSGi api imho.
> I certainly did not want to start a flame war here ;-)  just to point
> to another possibility.
>    

No flame war, just a discussion which helps us to understand perceived
benefits of other solutions and to educate about our solution.

As Clement points out, the whiteboard handler is totally an extra thing
and has nothing to do with the core features of iPOJO. Actually, it
demonstrates the extensibility of iPOJO via handlers. If you check out
the iPOJO slides from the OSGi community event last year (in our
documentation area), you will see there is no mention of this anywhere
as well as no OSGi API.

-> richard

> On Thu, Jun 18, 2009 at 17:03, Richard S. Hall<heavy@...>  wrote:
>    
>> On 6/18/09 10:56 AM, Guillaume Nodet wrote:
>>      
>>> Yeah, dependency injection, the fact that you can inject much more
>>> things than just simple values (collections, maps, arrays.
>>>
>>>        
>> This doesn't make sense to me. Dependency injection is covered by iPOJO.
>> Property injection is no DI, it is configuration injection, no? At a
>> minimum, let's try to differentiate between the two.
>>
>> Are you saying collections, maps, arrays are simple values? If so, what kind
>> of complex values supported by BP?
>>
>> ->  richard
>>
>>      
>>> You can also define custom converters to handle legacy code.
>>>
>>> On Thu, Jun 18, 2009 at 16:50, Richard S. Hall<heavy@...>
>>>   wrote:
>>>
>>>        
>>>> On 6/18/09 10:35 AM, Guillaume Nodet wrote:
>>>>
>>>>          
>>>>> FWIW, Spring-DM is being standardized as Blueprint services.
>>>>> You can find an implementation of the spec (soon to be published) at
>>>>>    http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint/
>>>>>
>>>>> Blueprint is much more powerfull wrt dependency injection than DS /
>>>>> iPojo.
>>>>>
>>>>>
>>>>>            
>>>> I'd like to hear how it is "much more powerful wrt to DI" than iPOJO...I
>>>> can
>>>> only assume you are referring to property injection, which could be more
>>>> flexible, but I cannot imagine anything else.
>>>>
>>>> ->    richard
>>>>
>>>>
>>>>          
>>>>> The runtime is<      300k, so it's not too eavyweight either.
>>>>>
>>>>> On Mon, Jun 15, 2009 at 15:31, Dmitry Skavish<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!
>>>>>>
>>>>>> --
>>>>>> Dmitry Skavish
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>>>
>>>
>>>        
>
>
>
>    

[Felix Meschberger-2]

Hi,

Todor Boev schrieb:
> I would
> not go with OSGi DS since it does not really do much to shield you from
> the service dynamics.

This sentence I do not understand: Service dynamics is one of the key
points of OSGi.

But it is correct, the current specification of DS requires a lot of
OSGi API to use: If you want the configuration on activation you need to
use an OSGi interface (ComponentContext) and have to implement a
predefined method (activate(ComponentContext)). Likewise, if you want to
access service registration properties you need to bind using the
ServiceReference.

With the next version of the specification, this will get a lot better:
The activate method can have any name and you can have the configuration
injected as a Map. Likewise you can be bound to the service object and
at the same time get the registration proeprties in a Map.

Regards
Felix

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Todor Boev]

> This sentence I do not understand: Service dynamics is one of the key
> points of OSGi.
>

The key usage of dynamics is hot code update. Direct service references plus
concurrent bundle updates make handling service dynamics quite disruptive to the
normal application code.You have to sprinkle synchronizations all over the place
and are not allowed to store services in final fields and pass them to
constructors. I have written quite a lot of bundles with complex internal
structures against the raw OSGi API and got despaired of how messy my
application code becomes when I mix in all the dynamics handling boilerplate.

Turns out you can have hot code update and still be able to code largely in a
normal Java style. Peaberry and Spring DM use dynamic proxies to shield the
application code from all the movement. iPojo does a similar thing by caching
the service objects in a thread local plus some bytecode magic.

Under OSGi DS the only way to have "stable" bundle internals is to use a static
dependency policy. This is costly because than the only way to release a service
object is to drop the entire component and make a new one. Under dynamic policy
on the other hand all the synchronization and care to release stale services is
back in my hands.

I tried to explain all this stuff in much greater detail here:

http://rinswind.blogspot.com/2009/05/service-dynamics-lazy-mans-way.html

It is a work in progress so I'd appreciate any input :)

Cheers
Todor


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Todor Boev]

Todor Boev wrote:
>
> Here's a descent comparison between Spring DM, OSGi DS and iPojo.
>
> http://www.slideshare.net/heiko.seeberger/jax-09-osgi-service-components-models
>

I actually meant to post this here detailed three way comparison:

http://www.slideshare.net/njbartlett/component-oriented-development-in-osgi-with-declarative-services-spring-dynamic-modules-and-apache-ipojo?type=presentation

Had hard time finding the proper link.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Felix Meschberger-2]

Hi,

Todor Boev schrieb:

>> This sentence I do not understand: Service dynamics is one of the key
>> points of OSGi.
>>
>
> The key usage of dynamics is hot code update. Direct service references plus
> concurrent bundle updates make handling service dynamics quite disruptive to the
> normal application code.You have to sprinkle synchronizations all over the place
> and are not allowed to store services in final fields and pass them to
> constructors. I have written quite a lot of bundles with complex internal
> structures against the raw OSGi API and got despaired of how messy my
> application code becomes when I mix in all the dynamics handling boilerplate.

Ah, I understand. I agree, that this might be (or is) cumbersome.

>
> Turns out you can have hot code update and still be able to code largely in a
> normal Java style. Peaberry and Spring DM use dynamic proxies to shield the
> application code from all the movement. iPojo does a similar thing by caching
> the service objects in a thread local plus some bytecode magic.
>
> Under OSGi DS the only way to have "stable" bundle internals is to use a static
> dependency policy. This is costly because than the only way to release a service
> object is to drop the entire component and make a new one. Under dynamic policy
> on the other hand all the synchronization and care to release stale services is
> back in my hands.

Agreed. And the cascading situation makes this even "worse", so to speak.

>
> I tried to explain all this stuff in much greater detail here:
>
> http://rinswind.blogspot.com/2009/05/service-dynamics-lazy-mans-way.html

Interesting and impressive.

Regards
Felix

>
> It is a work in progress so I'd appreciate any input :)
>
> Cheers
> Todor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[gnodet]

Great presentations ! Thx for sharing those links.

FWIW, the blueprint spec fixes most of the flaws described for
Spring-DM (layziness, bean lifecycles / required dependencies), and
the implementation i'm working on has a much lower footprint (< 300k)
than Spring-DM.

Also, the blueprint spec defines the source of the metadata as being
XML descriptors, but the real reference for the metadata is a set of
objects describing the beans, services and references, so we can
easily imagine having a different source for this metadata rather than
the XML (though it would be implementation specific atm).

On Sat, Jun 20, 2009 at 23:29, Todor Boev<t.boev@...> wrote:

> Todor Boev wrote:
>>
>> Here's a descent comparison between Spring DM, OSGi DS and iPojo.
>>
>> http://www.slideshare.net/heiko.seeberger/jax-09-osgi-service-components-models
>>
>
> I actually meant to post this here detailed three way comparison:
>
> http://www.slideshare.net/njbartlett/component-oriented-development-in-osgi-with-declarative-services-spring-dynamic-modules-and-apache-ipojo?type=presentation
>
> Had hard time finding the proper link.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dmitry Skavish]

Hi Guillaume,

I am curious about this blueprint implementation you mentioned. Is it
opensourced? If yes is there any link I can check it out? If no why not? :)
Thanks!

On Sun, Jun 21, 2009 at 5:28 AM, Guillaume Nodet <gnodet@...> wrote:

> Great presentations ! Thx for sharing those links.
>
> FWIW, the blueprint spec fixes most of the flaws described for
> Spring-DM (layziness, bean lifecycles / required dependencies), and
> the implementation i'm working on has a much lower footprint (< 300k)
> than Spring-DM.
>
> Also, the blueprint spec defines the source of the metadata as being
> XML descriptors, but the real reference for the metadata is a set of
> objects describing the beans, services and references, so we can
> easily imagine having a different source for this metadata rather than
> the XML (though it would be implementation specific atm).
>
> On Sat, Jun 20, 2009 at 23:29, Todor Boev<t.boev@...> wrote:
> > Todor Boev wrote:
> >>
> >> Here's a descent comparison between Spring DM, OSGi DS and iPojo.
> >>
> >>
> http://www.slideshare.net/heiko.seeberger/jax-09-osgi-service-components-models
> >>
> >
> > I actually meant to post this here detailed three way comparison:
> >
> >
> http://www.slideshare.net/njbartlett/component-oriented-development-in-osgi-with-declarative-services-spring-dynamic-modules-and-apache-ipojo?type=presentation
> >
> > Had hard time finding the proper link.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Dmitry Skavish

[Dmitry Skavish]

Hi Todor,
very informative post! thanks.

http://rinswind.blogspot.com/2009/05/service-dynamics-lazy-mans-way.html
>
> It is a work in progress so I'd appreciate any input :)


--
Dmitry Skavish

[gnodet]

The blueprint implementation is available at
   http://svn.apache.org/repos/asf/geronimo/sandbox/blueprint

Just tell me if you have any problems building it (running "mvn" should work).
The target bundle will be available in
blueprint-bundle/target/blueprint-bundle-1.0.0-SNAPSHOT.jar

On Mon, Jun 22, 2009 at 18:19, Dmitry Skavish<skavish@...> wrote:

> Hi Guillaume,
>
> I am curious about this blueprint implementation you mentioned. Is it
> opensourced? If yes is there any link I can check it out? If no why not? :)
> Thanks!
>
> On Sun, Jun 21, 2009 at 5:28 AM, Guillaume Nodet <gnodet@...> wrote:
>
>> Great presentations ! Thx for sharing those links.
>>
>> FWIW, the blueprint spec fixes most of the flaws described for
>> Spring-DM (layziness, bean lifecycles / required dependencies), and
>> the implementation i'm working on has a much lower footprint (< 300k)
>> than Spring-DM.
>>
>> Also, the blueprint spec defines the source of the metadata as being
>> XML descriptors, but the real reference for the metadata is a set of
>> objects describing the beans, services and references, so we can
>> easily imagine having a different source for this metadata rather than
>> the XML (though it would be implementation specific atm).
>>
>> On Sat, Jun 20, 2009 at 23:29, Todor Boev<t.boev@...> wrote:
>> > Todor Boev wrote:
>> >>
>> >> Here's a descent comparison between Spring DM, OSGi DS and iPojo.
>> >>
>> >>
>> http://www.slideshare.net/heiko.seeberger/jax-09-osgi-service-components-models
>> >>
>> >
>> > I actually meant to post this here detailed three way comparison:
>> >
>> >
>> http://www.slideshare.net/njbartlett/component-oriented-development-in-osgi-with-declarative-services-spring-dynamic-modules-and-apache-ipojo?type=presentation
>> >
>> > Had hard time finding the proper link.
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>
> --
> Dmitry Skavish
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...