Warning: This is a facade provided for use by user code, not for implementation by user code. User implementations of this interface are highly likely to be incompatible with future releases of the product at both binary and source levels.
Sometimes it is necessary for the code outside the OSGi framework and the code inside to communicate. While this should be kept to an absolute minimum in some cases it is unavoidable. This is where bridge services are used. A bridge service is simply an OSGi service that is used to bridge the gap created by the OSGi framework.
Although the OSGi framework does protect itself against the environment there is one place where that protection can break down and that is with the context class loader. The OSGi framework needs to set its own context class loader to make sure that bundles cannot use it to circumvent its module layer. Similarly, the environment needs to use its own class loader to ensure that it does not access classes from within the OSGi framework.
As bridge services cross the gap between the environment and the framework they need to make sure that the context class loader is set up correctly for the code that is about to be executed. Ideally, this would mean that every method on every object that is passed between the two is modified to set the context class loader before invoking any code and reset it afterwards.
At the moment only interfaces can be used as services because that allows a {@link java.lang.reflect.Proxy} objects to be automatically created towrap the service before it is registered with OSGi. Unfortunately, this does not solve all the problem as it does not deal with objects passed as parameters and returned as values. These need to be explicitly handled by the calling code and the returning code respectively.
Bridge services that only use methods that return primitive values (or their autoboxed objects), {@link String}s, or arrays of the previous types are safe but services that return user defined objects may not be as the objects may make use of the context class loader. In this case the objects must be wrapped either in a {@link java.lang.reflect.Proxy}, or in some custom code.
As special care has to be taken when providing and using them only those services that have been explicitly exported should be accessible from outside the framework and so exported services have an additional property to control that and the method provided to access the services uses a filter to ensure that service was exported. The same applies to imported services but unfortunately, it is not possible to prevent access to those services by the normal mechanism as there is no way to say that the service must be retrieved by a filter. Care must therefore be taken to ensure that imported bridge services are not misused.
| |