> @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. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
