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 On Mon, Feb 17, 2014 at 10:01 AM, Christian Schneider < [email protected]> wrote: > Yes .. private or even no interfaces would practically hide the service > from outside usage. Of course it could still be used with reflection but I > think that is not an issue. > > The question is though if we should mark such a service as private in some > way. I think this would allow the tooling to present a much better overview > over the components. > > So for scr:list I would like to see just the public components: > ID State Component Name > [0 ] [ACTIVE ] org.apache.karaf.scr.command.Commands > [9 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.QueryCommand > [10 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.SelectCommand > [12 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.ExecuteCommand > [13 ] [ACTIVE ] net.lr.tutorial.karaf.db. > command.ShowTablesCommand > > instead of: > ID State Component Name > [0 ] [ACTIVE ] org.apache.karaf.scr.command.Commands > [9 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.QueryCommand > [10 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.SelectCommand > [11 ] [ACTIVE ] net.lr.tutorial.karaf.db.service.DbSelect > [12 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.ExecuteCommand > [13 ] [ACTIVE ] net.lr.tutorial.karaf.db. > command.ShowTablesCommand > [14 ] [ACTIVE ] net.lr.tutorial.karaf.db.service.DbAccess > [15 ] [ACTIVE ] net.lr.tutorial.karaf.db.command.DbNameCompleter > > Then I could use scr:list --private <bundleid> or similar to also show the > private components of a bundle if I want to dig into it. > > So like described in my other mail I am pretty sure we could tweak the scr > command to allow this right now based on package exports I think it would > be great to have a public/private flag on the service itself. > > What do you think? > > Christian > > > > On 17.02.2014 10:40, Felix Meschberger wrote: > >> 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 >> >> >> > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
