如何隐藏 OSGi 服务以便其他捆绑包无法找到它们？

Question

I am developing an application that is build on top of Apache Felix and JavaFX. The application can be extended by 3rd party bundles that implement a specific Interface and make it available to the OSGi Runtime Service Registry.

The problem is that those bundles (or plugins) should not be able to retrieve any of the services that are just used internally by my application. An example would be a PersistenceService that is used to save the processed data. Plugins are (in my application) by definition not allowed to store any data through my service but are allowed to save them through a specific service designed for the plugins only.

I had the idea of using the FindHook Interface offered by OSGi to filter out those requests but that didn't work good. Obviously, to make it work, the bundle needs to me loaded at the very start, eve before my core application gets loaded. I ensured this happens by specifying the start level for this bundle using the felix.auto.deploy.install.1 = "file\\:bundles/de/zerotask/voices-findhook/0.1-SNAPSHOT/voices-findhook-0.1-SNAPSHOT.jar"

As far as I understood, the start level of the system bundle will be 1 which means that my bundle should always be loaded right after the system bundle.

Here is my implementation of the FindHook interface:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.Arrays;
import java.util.Collection;
import java.util.HashSet;
import java.util.Set;

import org.osgi.framework.BundleContext;
import org.osgi.framework.ServiceReference;
import org.osgi.framework.hooks.service.FindHook;

/**
 *
 * @author PositiveDown
 */
public class VoicesFindHook implements FindHook {

private static Logger log = LoggerFactory.getLogger(VoicesFindHook.class);

private static final String[] INTERNAL_BUNDLE_TABLE = new String[]{
    "de.zerotask.voices-core-actions",
    "de.zerotask.voices-findhook",
    "de.zerotask.voices-interfaces-persistable",
    "de.zerotask.voices-models",
    "de.zerotask.voices-models-actions",
    "de.zerotask.voices-services-configuration-internal",
    "de.zerotask.voices-services-input-internal",
    "de.zerotask.voices-services-licenses-internal",
    "de.zerotask.voices-services-modelsmanager-internal",
    "de.zerotask.voices-services-persistence-internal",
    "de.zerotask.voices-services-window-internal",
    "de.zerotask.voices-ui-dialogs-about",
    "de.zerotask.voices-ui-dialogs-newprofile",
    "de.zerotask.voices-ui-dockable-listview",
    "de.zerotask.voices-ui-dockable-properties",
    "de.zerotask.voices-ui-layout",
    "de.zerotask.voices-utils-io",
    "de.zerotask.voices-utils-services",
    "de.zerotask.voices-utils-ui"
};

private static final String[] INTERNAL_SERVICES_TABLE = new String[]{
    // model services
    // configuration service
    "de.zerotask.voices.services.configuration.IConfiguration",
    // window service
    "de.zerotask.voices.services.window.IWindowService",
    // persistence services
    "de.zerotask.voices.services.persistence.IPathResolver",
    "de.zerotask.voices.services.persistence.IPersistenceService"
};

private static final Set<String> INTERNAL_BUNDLES = new HashSet<>(Arrays.asList(INTERNAL_BUNDLE_TABLE));

private static final Set<String> INTERNAL_SERVICES = new HashSet<>(Arrays.asList(INTERNAL_SERVICES_TABLE));

@Override
public void find(BundleContext context, String name, String filter, boolean allServices, Collection<ServiceReference<?>> references) {
    // only allow the usage of internal interfaces from internal packages
    String symbolicName = context.getBundle().getSymbolicName();
    // debug
    log.debug("Processing Bundle {} and service {}", symbolicName, name);
    // if the service is one of the internal ones, proceed
    if (INTERNAL_SERVICES.contains(name)) {
        // retrieve the bundle id
        log.debug("Service {} is in internal table", name);
        // if the name is not in the internal bundle table, remove all service references
        if (!INTERNAL_BUNDLES.contains(symbolicName)) {
            log.debug("Bundle {} not in internal table => removing service references...", symbolicName);
            // remove them
            references.clear();
        }
    }
}
}

The idea is to have a table of internal bundles``` and internal services```. Each time a service is looked up, the hook will check if it is an internal service. If this is the case, it will also check if the caller bundle is an internal bundle. If that's not true, the hook will remove all services found from the collection.

I am by far no OSGi expert but this method should work because it is based on the SymbolicName s which are unique in each container.

I have tested the above code with two small test bundles. One providing the interface + implementation and the other one consuming it. I changed the hook so it will not return any services for the consumer bundle (to just simply check if it works).

No my problem is, the consumer bundle gets somehow loaded first. I have no idea why. By doing this it basically breaks my loading property set in the properties file. I am not sure if this helps but the provider bundle's name starts with an 'y', the consumer one with an 't' and the hook one with an 'v'. The funny thing is, Felix is loading them in alphabetically order.

I would really appreciate any help here.

Answer 1

Services are implicitly available to every bundle – that is the purpose of services after all.

You can work around this with various hacks like FindHooks etc, but as you have already discovered you are constantly fighting against the true nature of the OSGi Framework and services.

It sounds more like you are creating an isolation system between a kernel and a user space, so that you cannot accidentally pollute the user area with kernel services and vice versa . The proper way (IMHO) to achieve this is with a separate OSGi Framework instance for the two areas. It's quite simple to run up a new Framework using the FrameworkFactory API. Then you can expose select packages and services from the kernel using the BundleContext of the system bundle of the user-area Framework.

However as BJ points out in comments, you may be over-engineering this. What's the worst that can happen if the plugins can see your system services? If those services are well designed then the answer should be "not a lot".

Answer 2

I see two options:

• ServicePermission , this is the standard way;

or

• ServiceFactory , you decide what bundle can get the real service. Others receive a fake implementation.