Bringing OSGi-DS to plain java applications

Fairly everything in e(fx)clipse is done with DS-Services when you run in an OSGi-Environment.

Still many of them don’t have any dependency on OSGi at all so most components we have can also run/get used in an ordinary Java-Environment (see the blog post about the code editor framework as an example). Since the beginning we published some of them through the ServiceLoader-API (and we’ll still keep it for those) but that has the draw back that you can not express relations between services.

Tonight I had a crazy idea: Could I read the DS-Component-Registration files in an none-OSGi environment and wire services together without using the ServiceLoader-API.

The result is JavaDSServiceProcessor. Our public service lookup API has been retrovited to use this internal service instead of ServiceLoader so if one now eg looks up our AdapterService like this:

import org.eclipse.fx.core.Util;
import org.eclipse.fx.core.adapter.AdapterService;

public class Test {
  public static void main(String[] args) {
    AdapterService adapterService = Util.getService(AdapterService.class).get();

will get a fully configured AdapterService. We currently don’t support everything from the DS-Spec (eg Properties are not yet support) but I’ll fill this gap soon.

This entry was posted in e(fx)clipse. Bookmark the permalink.

7 Responses to Bringing OSGi-DS to plain java applications

  1. Scott Lewis says:

    Hi Tom. Another approach to using OSGi services (service reg) and DS and other extensions (e.g. remote services) in java is to use Apache Connect. Connect was formerly known as PojoSR and implements the OSGi service registry without the Bundle layer. I’ve added on a ServiceRegistry API accessed via ServiceLoader in this project:

    As you can see from our examples, this allows the use of DS, Remote Services and/or other Service Registry extensions.

    There is talk in the EEG of standardizing Apache Connect, but so far it seems to be talk.

  2. Ben says:

    This blog post made my day.

    The ECF approach is interessting, but for now I’ll go with Tom’s solution as it has no boilerplate code on client side.

    • slewis2002 says:

      Not sure what you mean by boilerplate code. The remote service examples in this repo are intentionally not using DS, but if you add either equinox or apache felix SCR implementation bundle you can have full-spec-compliant DS (all running java-only/no OSGi bundle layer)

      • Ben says:

        The remote services need some setup to run, whereas the AdapterService just has above two lines on client side. This seemed suitable to me for a quick solution. However in the long run SCR are the way to go.

      • Scott Lewis says:

        Hi Ben.

        The examples that I provide do have some code to export remote services, but this is by choice…done to show the use of java code to explicitly export remote services. For these examples, I intentionally left out the SCR bundle. With SCR, there is no setup code needed, as remote services are registered and exported via SCR and the service registry.

        But if remote services aren’t to be used at all, the only code needed to access the service registry is:

        ServiceRegistry serviceRegistry = ServiceLoader.load(ServiceRegistryFactory.class)

        Everything else in

        is either code to enable remote services debugging or the TimeService registration, which when SCR is present is done via SCR instead.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.