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
