I had the impression to read an e-mail from Peter Kriens ;)

I know DS interests. My point was more DS or Blueprint vs OSGi "native". It was not between DS and Blueprint.

I agree with your points, and they make sense. I have no problem to think about this for Karaf 4.0.0, but I would plan tests (usage/benchmark), etc as it may have an impact for users.

Regards
JB

On 01/20/2014 12:06 PM, Ioannis Canellos wrote:
@Ioannis: agree, but I wonder the value of using DS instead of Blueprint, or
the "overwork plumbing" to use pure OSGi insteand of DS or Blueprint ;)

The value of using DS instead of Blueprint focuses around those areas:
i) smaller footprint
ii) proxy free
iii) improved lifecycle management of components.
iv) you get metatype metadata for free (less maintenance).
v) increased control /  transparency -> way easier to diagnose issues
(see scr commands and scr mbeans).

 From my point of view the biggest problem with blueprint is that is
the lacking lifecycle management features of DS.
So in many cases, we currently register services, commands & mbeans,
even if the core service required for all those is missing. Then we
are using proxies or service trackers to wait or check if the service
is actually there.
Of course, this is no biggie (other than initializing and registering
unusable objects) when we know that eventually everything is going to
be there, but when you want to try to make things as decoupled as
possible and go for the minimum this can be a problem. Why? because
you can end up waiting forever on services that wait for a proxy and
so on.

An other really important point, is that when you are using DS, you
are able to see and interact with the state of your components, see
which components have unsatisfied dependencies and how your components
are wired together. With blueprint everything is a black box.

For these reasons I also feel that it doesn't worth going for a pure
OSGi api solution, since you gain (i) & (ii) but still loose all the
others and also have the burden of maintenance.


--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to