I guarantee that you will waste a lot of time on Find Hooks. Please don’t go that route!
The service *should* already be private so what you need to do is work out why that is not the case. Both bundles should simply contain the interface package as a private package. If either of them need to export the package (e.g. because other bundles also need it) then they must NOT import it. Regards, Neil > On 17 Jun 2016, at 13:10, Vincent Vandemeulebrouck > <[email protected]> wrote: > > 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.* --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
