I am sure it is possible to do the injection by hand. This means though
that I revert all positive aspects of a DI framework. For example in my
case I want the commands to share a common DBAccess instance. At the
same time I do not want this instance to be public as it is only needed
for the commands in this case.
I can not imagine that I can use DS together with any DI framework as
both kinds components would not know about each other. So I think it
would make sense to let DS do a certain level of
intra bundle wiring.
Do you have any pointer for me to a DS application that is larger than
an example like in my case. I would like to see how other people solved
this wiring.
Christian
On 17.02.2014 15:34, Neil Bartlett wrote:
The XRay plugin does have an option to highlight services where the
interface package is private... it is highlighted in red as an error.
However I think you may be looking at this the wrong way around. It
sounds like you have mapped each individual bean in your blueprint
container to a DS component, however in DS a Component is much more
than just a bean: it has a full lifecycle including service binding.
In Blueprint only the container has a lifecycle.
Another way of looking at this is that in Blueprint there is just one
component per bundle (the container) and it is constructed out of a
combination of XML and Java. In DS there can be multiple components
per bundle, and they are constructed principally using Java, though
you can use something like Spring or Guice on the inside of a
component if you really want to.
So I think the desire for intra-bundle wiring of DS components comes
from making those components too small and granular, which in turn
comes from slavishly mapping Blueprint beans onto components. You
might want to look again at that mapping and devise a set of
components where each one includes the functionality of several beans.
Regards,
Neil
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
