Hi DS strictly goes through the service registry: All components can only be wired by being registered as services and referring to services.
Yet, a registered service is not required to be registered with an exported (public) interface. It is perfectly fine to have services registered and referred to with bundle-private interfaces (we also do that at times in our application). Regards Felix Am 17.02.2014 um 10:10 schrieb Christian Schneider <ch...@die-schneider.net>: > This weekend I ported one of my examples from blueprint to declarative > services. > See https://github.com/cschneider/Karaf-Tutorial/tree/master/db/command2 > > While it worked pretty well in general I have one concern with DS about > public services vs internal component wiring. > > In my example I intended to export the components implementing Action to be > exported as OSGi services as these have to be picked up by a karaf module. > This worked fine of course. > On the other hand I have some internal components like DbAccess and DbSelect > that I simply wanted to wire into my public services but that should not be > public. > In blueprint I have a clear separation there. Only the beans I export with a > service element are visible to the outside. For DS I have not found such a > feature. > > How can I achieve the same hiding of internals in DS? I can imagine that I > simply do not export the classes / interfaces that are internal. Still they > will all appear in the list of components if I use the karaf command > scr:list. Of course I want see the internal wirings sometimes but when I look > at the whole OSGi framework I think it would be great to be able to only see > the public components at first. > > Is this possible somehow? > > Christian > > > -- > 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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
