In our case, the reason behind the bundle-private service is that it is based on different other public services.
The current solution we have is to instantiate an object with all the requirements as construction parameters. It becomes impractical because we have to repeat the exact same initialization ((add 3-4 requires, creation, call to the interesting method) in lots of different places just to have access to a very basic information. We end up with a lot of duplication in different components of different bundles. So an approach to simplify was to use a bundle private service that aggregates other services. We tried different approaches, but have not found how to filter correctly, the other bundle service is visible. Basically, it is the same class (could be in a different version, but same java class & package, providing itself as implementation), loaded by another ClassLoader. I will investigate how the https://osgi.org/javadoc/r6/core/org/osgi/framework/hooks/service/FindHook.html, can be used. Thanks for the advice. *--Vincent Vandemeulebrouck | *Architect - UL MIDDLE and Extensions *| ULLINK | *D: +33 1 44 50 52 02* | *T: +33 1 49 95 30 00* | *23-25 rue de Provence, 75009 Paris, FRANCE *|* [email protected] *| * <http://www.ullink.com/> 2016-06-17 13:53 GMT+02:00 Neil Bartlett <[email protected]>: > You don’t need to use either registry hooks or regions for this. If the > service interface package is private within the bundle (or if each bundle > does not import the interface package from the other bundle) then your > service will only be visible within its own bundle. This is known as > service compatibility filtering — it is a core feature of the Service > Registry and it exists precisely to prevent the ClassCastException you are > talking about. > > I also agree with David’s second paragraph. If the “service” is only used > within one bundle then why make it a service at all? Java’s “new” keyword > is more concise and convenient. > > Regards, > Neil > > > > On 17 Jun 2016, at 12:47, David Bosschaert <[email protected]> > wrote: > > > > You can also use OSGi Service Registry Hooks to enforce this, see here: > > > https://osgi.org/javadoc/r6/core/org/osgi/framework/hooks/service/package-summary.html > > You would implement the service hooks in a separate bundle to control > which > > client gets which service. > > > > On the other hand, if the object provided by the bundle should only be > used > > by its own bundle, I'm wondering whether services are the best approach. > > You could consider just instantiating the object directly if it's only > used > > within its own bundle. Services are really aimed at being useful outside > of > > the local bundle scope... > > > > Best regards, > > > > David > > > > On 17 June 2016 at 11:45, Guillaume Nodet <[email protected]> wrote: > > > >> You can investigate the use of equinox regions. You can define regions > and > >> visibility between regions. > >> > >> 2016-06-17 12:27 GMT+02:00 Vincent Vandemeulebrouck < > >> [email protected]>: > >> > >>> I need two different bundles to have the same private iPojo service, to > >> be > >>> used internally. It is defined in a shared library, included in both > >>> bundle. > >>> > >>> How can I enforce that the requiring service get the service from their > >> own > >>> bundle? > >>> > >>> Currently, as each bundle has the same service and same > specifications, I > >>> end-up having the private service from the other bundle injected, > causing > >>> some illegal accesses. > >>> > >>> Bundles are implemented in java. The issue is that each bundle has its > >> own > >>> ClassLoader, and injecting the class from the othe ClassLoader causes a > >>> ClassCastException. > >>> > >>> > >>> *--Vincent Vandemeulebrouck | *Architect - UL MIDDLE and Extensions *| > >>> ULLINK | *D: +33 1 44 50 52 02* | *T: +33 1 49 95 30 00* | *23-25 rue > de > >>> Provence, 75009 Paris, FRANCE *|* [email protected] > >> *| * > >>> > >>> -- > >>> *The information contained in or attached to this email is strictly > >>> confidential. If you are not the intended recipient, please notify us > >>> immediately by telephone and return the message to us.* > >>> > >> > >> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> ------------------------ > >> Red Hat, Open Source Integration > >> > >> Email: [email protected] > >> Web: http://fusesource.com > >> Blog: http://gnodet.blogspot.com/ > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- *The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us.*
