Miles To Code Before I Sleep

Restlet Extension for OSGi Environments 0.5.1 Released

Bryan Hunt — Mon, 21 Nov 2011 04:26:14 +0000

Restlet Extension for OSGi Environments 0.5.1 is a maintenance release to be compatible with the latest Restlet p2 repository. There were no changes to the code – only fixes to the feature dependencies.

eTrack EMF Tutorial

Bryan Hunt — Mon, 07 Nov 2011 14:00:54 +0000

I’ve made a little more progress with eTrack and I now have two complete EMF tutorials available. Creating the Entity Domain Model walks you through creating an EMF ecore model for the Entity domain, the corresponding genmodel, and how to use the generated editor. Refactoring the Entity Domain Model shows you how to refactor an EMF model into two separate models. These are the first tutorials available in a series that will cover the building of an entire application. If you would like to contribute to the project, please let me know or open an issue.

Restlet Extensions for OSGi Environments 0.5.0 Released

Bryan Hunt — Mon, 17 Oct 2011 14:00:00 +0000

I have released Restlet Extension for OSGi Environments version 0.5.0. This project provides a framework for building RESTful OSGi web services using dynamic applications, routers, filters, and resources. The project has been renamed from Restlet integration with OSGi & Equinox, and has also been refactored to be a Restlet extension. This build is temporary until the extension is officially released as part of Restlet. This release requires Restlet 2.1M7 or later.

MongoEMF 0.4.0 Released

Bryan Hunt — Wed, 05 Oct 2011 17:54:09 +0000

I have released MongoEMF 0.4.0. Some of the notable changes include:

Reading objects from a query Result has been significantly improved
Write performance for bulk stores has improved
Added MongoResourceImpl for improved load performance when using URI mappings
Added OPTION_USE_ID_ATTRIBUTE_AS_PRIMARY_KEY to store objects using the ID attribute value as the MongoDB primary key

For a complete list of the changes, see the Release Notes.

OSGi at REST

Bryan Hunt — Fri, 01 Jul 2011 03:33:29 +0000

Introduction

I’ve been working on a project to make building RESTful OSGi web applications as simple as creating a basic OSGi service, and I think I have a solution that comes pretty close to this goal. The project is currently called restlet-integration-with-equinox as hosted on EclipseLabs. I am in the process of moving the project to GitHub, and it will be renamed to Restlet Extension for OSGi Environments. This framework integrates the Restlet RESTful web framework with OSGi allowing you to dynamically register resources, filters, routers, and applications as part of a RESTful web application.

The project originally started out supporting the registration of applications and resources as OSGi services or with an Equinox extension point. This all worked fine until I started adding the ability to register routers and filters. The code became complicated and ugly, so I branched the repository and started over. As the second iteration progressed, it too became complicated, and it occurred to me that the core of the problem (delayed dynamic binding) was identical to the problem that OSGi declarative services has to solve. That’s when I had that AH-HA moment where the problem becomes clear, and you get to delete all of that ugly, complicated, code. The solution is to use OSGi declarative services and its dynamic binding capabilities to stitch together the resources, filters, routers, and applications. And, since you are using OSGi services, you can add and remove resources at runtime and it all just works.

Framework

The Restlet Extension for OSGi Enironments framework is organized as a set of service components and interfaces for you to register as declarative services to form your RESTful web application. Using these service components, it’s possible to implement a simple application with a router and some resources, or a very complex graph of filters, routers, and resources as demonstrated below.

Here is the API specification for the service interfaces:

Here is the API specification for the service components (I have omitted the service interfaces that each provider implements):

FilterProvider and ResourceProvider are abstract and must be extended as described below. RouterProvider and ApplicationProvider can be used without extending them. The remainder of this post will walk you through examples of creating RESTful web applications using this technology.

Setup

Before you begin development of your application, the target platform needs to be crated with the following frameworks:

Equinox 3.7
Restlet JEE 2.0.8
Restlet Extensions for OSGi Environments 0.3.0

If you would like to minimize your target platform, the following bundles are the minimum required:

javax.servlet
org.eclilpse.equinox.common
org.eclipse.equinox.ds
org.eclispe.equinox.http.jetty
org.eclipse.equinox.http.servlet
org.eclipse.equinox.util
org.eclipse.osgi
org.eclipse.osgi.services
org.mortbay.jetty.server
org.mortbay.jetty.util
org.restlet
org.restlet.ext.servlet
org.eclipselabs.restlet
org.eclipselabs.restlet.servlet

If you are not familiar with setting up your target platform, here are the detailed steps:

Download Restlet JEE 2.0.8 and Restlet Extensions for OSGi Environments 0.3.0. You do not need to download Equinox – we’ll get that from a p2 repository.
Uncompress the downloads into a targets directory.
Launch Eclipse (I’m using Indigo) and select Preferences -> Plug-in Development -> Target Platform.
Click Add…
Choose Nothing: Start with an empty target definition.
Click Next
Name the target platform.
Click Add…
Choose Directory and click Next.
Add /restlet-jee-2.0.8/lib
Click Finish.
Click Add…
Choose Directory and click Next.
Add /restlet-ext-osgi
Click Finish.
Click Add…
Choose Software Site.
Work with: http://download.eclipse.org/releases/indigo.
Expand EclipseRT Target Platform Components.
Check Equinox Target Components.
Click Finish.
Click Finish.
Check the target definition you just created to make it Active.
Click OK.

Let’s test the target definition. Create an OSGi launch configuration with the following bundles:

javax.servlet
org.eclipse.equinox.http.jetty
org.eclipse.equinox.http.servlet
org.eclipse.osgi
org.eclipse.osgi.services
org.mortbay.jetty.server
org.mortbay.jetty.util

Set Default Auto-Start: true (not ideal, but it gets you up and running quickly) and add the following VM argument: -Dorg.osgi.service.http.port=8080.

Run the application and point your web browser to http://localhost:8080/. You should get a 404 error. This lets you know that jetty is responding to your request, but there are currently no resources to handle the request. For more information on setting up OSGi as a web server, see my blog post: OSGi as a Web Application Server.

Hello RESTful World

For this tutorial we are going to create a single resource at the URI http://localhost:8080/hello with a plain text representation. We need to create and wire together three objects: Application, Router, and ServerResource. Start by creating a new Plug-in Project called org.eclipselabs.restlet.examples.app. You do not need a bundle activator.

Open the MANIFEST.MF and add the following imported packages:

org.eclipselabs.restlet
org.restlet
org.restlet.resource

Create a new package: org.eclipselabs.restlet.examples.app and add the following HelloResource:

package org.eclipselabs.restlet.examples.app;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class HelloResource extends ServerResource
{
  @Get("txt")
  public String sayHello()
  {
    return "Hello RESTful World";
  }
}

In that same package, add the following HelloResourceProvider:

import org.eclipselabs.restlet.ResourceProvider;
import org.restlet.Context;
import org.restlet.resource.Finder;

public class HelloResourceProvider extends ResourceProvider
{
  @Override
  protected Finder createFinder(Context context)
  {
    return new Finder(context, HelloResource.class);
  }
}

At the root of the project create an OSGI-INF folder to hold our service declarations. In the OSGi-INF folder, create the following declarative service as application.xml:

Create the following declarative service as router.xml:

Create the following declarative service as hello.xml:

If you are not using the component definition editor to create your declarative services, be sure to add the following to the MANIFEST.MF:

Service-Component: OSGI-INF/application.xml, OSGI-INF/router.xml, OSGI-INF/hello.xml

You are now ready to run and test your web application. Add the following bundles to the launch configuration you created in the Setup step:

org.eclipselabs.restlet.examples.app
org.eclipse.equinox.common
org.eclipse.equinox.ds
org.eclipse.equinox.util
org.eclipselabs.restlet
org.eclipselabs.restlet.servlet
org.restlet
org.restlet.ext.servlet

Run the application and point your browser to http://localhost:8080/hello. You should see “Hello RESTful World”.

One of the neat features of Restlet is that you can specify more than one representation in a resource. Let’s add an HTML representation to our hello resource:

package org.eclipselabs.restlet.examples.app;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class HelloResource extends ServerResource
{
  @Get("txt")
  public String sayHello()
  {
    return "Hello RESTful World";
  }

  @Get("html")
  public String getDocument()
  {
    StringBuilder html = new StringBuilder();
    html.append("\n");
    html.append("  \n");
    html.append("    Hello RESTful World\n");
    html.append("   \n");
    html.append("\n");
    return html.toString();
  }
}

Now, when you reload http://localhost:8080/hello in your browser, you should see “Hello RESTful World” in a Heading 2 style. The complete solution for this example application can be downloaded from the Restlet Extensions for OSGi Environments downloads page.

Applications

Your OSGi web application will consist of one or more Restlet Application instances. An application is created by declaring an OSGi service component of type ApplicationProvider which provides the service IApplicationProvider, and has an “alias” property that specifies the root path of the application. The alias of each Restlet application in your OSGi application must be unique, start with “/” and not end with “/” with the exception of “/” itself. It should not be necessary to extend ApplicationProvider, but you must declare the service in your own bundle. The ApplicationProvider has a dependency on the IRouterProvider service. This dependency should be declared as static with a cardinality of 1..1 and bind functions (un)bindRouterProvider().

Suppose you wanted to create more than one Application. Each Application needs its own instance of a Router. How does OSGi declarative services know which IRouterProvider to bind to which ApplicationProvider? When you declare the dependency from ApplicationProvider to IRouterProvider, there is a target parameter you can set to specify the exact IRouterProvider to bind against. Here is an example of declaring two applications each binding to a unique router using the component.name property given to the service instance.

Routers

Every Restlet Application instance needs at least one Router instance. Technically speaking, this isn’t entirely true, but for all practical purposes, you are going to want a Router. A router is created by declaring an OSGi service component of type RouterProvider which provides the service IRouterProvider. The RouterProvider has a dependency on IResourceProvider and IRouterProvider services. The dependency on IResourceProvider should be declared as dynamic with a cardinality of 1..n and bind functions (un)bindResourceProvider(). This allows more than one resource to bind to a router and allows the resources to come and go without taking down the application. The dependency on IRouterProvider is optional and if declared should be dynamic with a cardinality of 0..1 and bind functions (un)bindDefaultRouterProvider(). The default router is asked to handle the URI routing when none of the resources attached to the router can handle the URI. The default router will make more sense when I discuss filters below.

When an application contains multiple routers, a target filter must be applied to the IResourceProvider services so that the resources are bound to the correct router. Since there can be many resources attached to a router, and each resource has a unique component.name, it’s not practical to use the component.name as a filter. I recommend giving each resource a property with a common value that is unique to a router. For example, if a resource has the property: type = public, then the router provider can bind to resources with the target (type = public). For the case of multiple applications, you may want to create a property that identifies the application such as: app = app1. The binding target is an LDAP filter, so you can combine both the app and type properties: (&(app = app1)(type = public)). Here is an example of declaring two routers for two different applications:

Resources

Resources are where you define exactly how an external client interacts with your application by responding to HTTP GET, PUT, POST, and DELETE requests. You must create two classes for every logical resource your application provides: the resource class itself extending ServerResource from the Restlet framework, and a resource provider extending ResourceProvider from the Restlet Extension for OSGi Environments framework. A resource is created by declaring an OSGi service component of the type you extended from ResourceProvider which provides the service IResourceProvider. The ResourceProvider does not require dependencies on any other services, but does require a property named paths which is a string array of paths relative to the application alias. The resource is registered with the router for each path declared in the paths property. Note that the PDE component definition editor does not support array properties, so you will have to switch to the Source tab to create the paths property. It is necessary to extend ResourceProvider to provide the classloading “glue” between Restlet and OSGi. Your resource provider should override Finder createFinder(Context context) and return an instance of a new Finder passing in the Context and the class of your resource.

Here is an example of two resources that respond to http://localhost:8080/hello and http://localhost:8080/example:

package org.eclipselabs.restlet.examples.app;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class HelloResource extends ServerResource
{
  @Get("txt")
  public String sayHello()
  {
    return "Hello RESTful World";
  }
}

import org.eclipselabs.restlet.ResourceProvider;
import org.restlet.Context;
import org.restlet.resource.Finder;

public class HelloResourceProvider extends ResourceProvider
{
  @Override
  protected Finder createFinder(Context context)
  {
    return new Finder(context, HelloResource.class);
  }
}

package org.eclipselabs.restlet.examples.resource;

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;

public class ExampleResource extends ServerResource
{
  @Get
  @Override
  public String toString()
  {
    return "Example";
  }
}

package org.eclipselabs.restlet.examples.resource;

import org.eclipselabs.restlet.ResourceProvider;
import org.restlet.Context;
import org.restlet.resource.Finder;

public class ExampleResourceProvider extends ResourceProvider
{
  @Override
  protected Finder createFinder(Context context)
  {
    return new Finder(context, ExampleResource.class);
  }
}



   
   
      
   
   
   	/example

Filters

Filters, just as the name implies, provide a mechanism for filtering a request as it is routed to the resource. The typical use-case for a filter is to protect resources from unauthorized access. Filters are created similar to resources by extending both Filter and FilterProvider. A filter is created by declaring an OSGi service component of the type you extended from FilterProvider which provides the service IFilterProvider. The FilterProvider does not require dependencies on any other services. Your filter provider should override Filter createFilter(Context context) and return an instance of a new Filter passing in the Context.

Filters can be wired to routers, resources, and other filters. The wiring is done by placing a service dependency on IFilterProvider in the component being filtered. Notice that RouterProvider, ResourceProvider and FilterProvider all extend from RestletProvider which has a bindFilterProvider() function. When declaring filters, you will probably want to use the component.name property as a target. Here is an example of an authentication and authorization filter:

package org.eclipselabs.restlet.examples.security;

import org.restlet.Context;
import org.restlet.Request;
import org.restlet.Response;
import org.restlet.data.Cookie;
import org.restlet.security.Authenticator;
import org.restlet.security.User;

public class SessionAuthenticator extends Authenticator
{
  public SessionAuthenticator(Context context)
  {
    super(context, false, new SessionEnroller());
  }

  @Override
  public boolean authenticate(Request request, Response response)
  {
    Cookie sessionCookie = request.getCookies().getFirst("session");
    Account account = AccountManager.getInstance().getAccount(sessionCookie.getSecond());

    if(account != null)
    {
      User user = new User(account.getCredential().getId(), account.getID());
      request.getClientInfo().setUser(user);
      return true;
    }

    return false;
  }
}

package org.eclipselabs.restlet.examples.security.providers;

import org.eclipselabs.restlet.components.FilterProvider;
import org.restlet.Context;
import org.restlet.routing.Filter;

import org.eclipselabs.restlet.examples.security.SessionAuthenticator;

public class SessionAuthenticationFilterProvider extends FilterProvider
{
  @Override
  protected Filter createFilter(Context context)
  {
    return new SessionAuthenticator(context);
  }
}

package org.eclipselabs.restlet.examples.security;

import org.restlet.Request;
import org.restlet.Response;
import org.restlet.security.Authorizer;
import org.restlet.security.Role;

public class SessionAuthorizer extends Authorizer
{
  @Override
  protected boolean authorize(Request request, Response response)
  {
    String accountID = request.getOriginalRef().getSegments().get(2);
    return accountID != null && accountID.equals(new String(request.getClientInfo().getUser().getSecret()));
  }
}

package org.eclipselabs.restlet.examples.security.providers;

import org.eclipselabs.restlet.components.FilterProvider;
import org.restlet.Context;
import org.restlet.routing.Filter;

import org.eclipselabs.restlet.examples.security.SessionAuthorizer;

public class SessionAuthorizerFilterProvider extends FilterProvider
{
  @Override
  protected Filter createFilter(Context context)
  {
    return new SessionAuthorizer();
  }
}

Service Dependency Injection

The Restlet Extensions for OSGi Environments framework provides support for dependency injection into your resources. If your resource extends InjectedServerResource and your resource provider creates an instance of InjectedFinder, you may then use @Inject in your resource to obtain references to other services such as the OSGi LogService. Here is an example of creating a resource that uses dependency injection with the OSGi LogService.

package org.eclipselabs.restlet.examples.resources;

import javax.inject.Inject;

import org.eclipselabs.restlet.di.eclipse.InjectedServerResource;
import org.osgi.service.log.LogService;

public class MyServerResource extends InjectedServerResource
{
  protected void log(int level, String message)
  {
    log(level, message, null);
  }

  protected void log(int level, String message, Throwable exception)
  {
    LogService logService = this.logService;

    if (logService != null)
      logService.log(level, message, exception);
  }

  @Inject
  private LogService logService;
}

References

Restlet – RESTful web framework
Restlet Extension for OSGi Environments – Restlet integration with OSGi
Restlet in Action – Book on Restlet
OSGi as a Web Application Server – Blog post on setting up OSGi as a web application server

Update Sept 28, 2011: Changed the project name to Restlet Extension for OSGi Environments and updated link to GitHub.

MongoEMF 0.3.2 Released

Bryan Hunt — Mon, 30 May 2011 19:24:53 +0000

I have released MongoEMF 0.3.2. This build adds support for storing OSGi log entries to MongoDB, and includes bug fixes for queries against dates and defaults values.

OSGi Logging in MongoDB

I’ve added a new bundle, org.eclispelabe.mongo.emf.log, that will convert an OSGi LogEntry into an EMF object and store it into MongoDB. Storing your OSGi log entries into MongoDB is a simple matter of configuring the ILogService (declarative service) with the OSGI ConfigurationAdmin service. I have created a LogServiceConfigurator helper class if you’d rather not deal with ConfigurationAdmin. The log service requires two properties:

baseURI
logLevel

The baseURI must be a valid MongoEMF collection URI of the form mongo://host/database/collection/ - for example: mongo://localhost/data/logs/. The logLevel is set to one of the logging levels defined in the OSGi LogService: LOG_ERROR, LOG_WARNING, LOG_INFO, and LOG_DEBUG.

Here is an example configuration using the LogServiceConfigurator for logging errors and warnings:

 
LogServiceConfigurator.configureLogService(URI.createURI("mongo://localhost/junit/logs/"), LogService.LOG_WARNING);

Querying Default Values

The standard EMF serializations: XML, XMI, and Binary do not store default values for attributes. The Mongo EMF binding was written this way as well to maintain consistency, but has the side effect of not being able to query objects based on attributes set to their default value. To solve this problem, we’ve added the option:

MongoDBURIHandlerImpl.OPTION_SERIALIZE_DEFAULT_ATTRIBUTE_VALUES

Setting this option to Boolean.TRUE when saving your object to MongoDB will force attributes with default values to be persisted to MongoDB. Here is a simple example:

Resource resource = resourceSet.createResource(uri);
resource.getContents().add(object);
HashMap options = new HashMap(1);
options.put(MongoDBURIHandlerImpl.OPTION_SERIALIZE_DEFAULT_ATTRIBUTE_VALUES, Boolean.TRUE);

try
{
  resource.save(options);
}
catch(IOException w)
{
  e.printStackTrace();
}

Introducing eTrack

Bryan Hunt — Sat, 19 Mar 2011 02:24:50 +0000

eTrack is an application that manages tasks. This project is meant to be a comprehensive tutorial that demonstrates the use of several Eclipse technologies, and current best practices for architecture, design, development, testing, build, and deployment. I would like the architecture to be as open as possible to accommodate different implementations of the various components of the application. There will, however, be a couple of things set in stone. The application will be based on OSGi, have a RESTful client / server architecture, and will use HTTP to communicate between client and server.

To get started, the initial implementation will use EMF for the domain model, MongoDB for the backing store, Restlet for the RESTful web services, Jetty for the web container, and simple HTML web pages for the client. It would also be nice, at some point, to have a GWT client, a SproutCore client, and Mylyn integration.

The project is hosted at EclipseLabs and the place to start is:

http://code.google.com/a/eclipselabs.org/p/etrack/

I would like to use Gerrit for source control, and Tycho and Jenkins for build, but I’m currently not aware of any free hosting for these services. If I can’t find free hosting, I might consider hosting on my home server and mirroring the source on GitHub for public access. Issue tracking will initially be done on the EclipseLabs Issues page until we can “eat our own cooking”.

Here is a first attempt at a domain model (I’ve taken a little liberty with the UML notation in that solid diamonds denote containment within the same resource while open diamonds denote cross-document containment):

I hope to start working on the implementation at EclipseCon. If you are interested in participating, please comment below describing what you would like to work on, or find me at EclipseCon and I’ll be happy to discuss this with you.

Mongo EMF

Bryan Hunt — Tue, 15 Mar 2011 14:00:10 +0000

If you have worked with the Eclipse Modeling Framework (EMF), then you already know how easy it is to create domain models. If you haven’t, then I highly recommend giving it a try. I develop all of my domain models using EMF. EMF has built-in support for persisting models to files in XMI, XML, and binary format. The persistence API is highly extensible, and I’ve recently been working with Ed Merks on some code that persists EMF models to MongoDB. The project is called mongo-emf and is hosted on EclipseLabs. Version 0.3.1 is being used in a real application and is fairly stable. This version supports all of the basic CRUD functions along with a basic query language for finding objects. This blog post will cover the CRUD functions while Ed Merks will have a blog post soon on using the query model.

One feature that I hope you will find attractive is that there are no annotations or XML configuration files required.

If you are attending EclipseCon 2011, I will be giving a talk titled Hardware Developer’s Workbench: a Case Study in which I will discuss how we are using this technology in our application.

Quickstart

Here’s an example on how easy it is to insert an object into MongoDB using EMF.

ResourceSet resourceSet = new ResourceSetImpl();
EList uriHandlers = resourceSet.getURIConverter().getURIHandlers();
uriHandlers.add(0, new MongoDBURIHandlerImpl());

Person user = ModelFactory.eINSTANCE.createMyObject()
user.setName("Test User");
user.setEmail("test@example.org");

Resource resource = resourceSet.createResource(URI.createURI("mongo://localhost/app/users/"));
resource.getContents().add(user);

try
{
  resource.save(null);
}
catch(IOException e)
{
  e.printStackTrace();
}

Let’s look at the code above in detail. Line 1 is the normal way you create an EMF ResourceSet. Lines 2 and 3 hook the MongoDB URI handler that interfaces EMF to MongoDB to the ResourceSet. Lines 5 – 7 set up the model instance. Line 9 creates the EMF resource using a URI that has a specific pattern explained below. Line 10 simply adds the model instance to the EMF Resource. Line 14 saves and inserts the model instance to MongoDB.

By adding just two additional lines of code and using a mongo URI, you are able to utilize the full power of EMF with your objects persisted in MongoDB.

Mongo EMF URIs

All EMF resources are identified by a URI. The URI you use when persisting models to MongoDB must have the form:

mongo://///

host is the hostname of the server running MongoDB (the port may be specified if not default)
database is the name of the MongoDB database to use
collection is the name of the MongoDB collection
id is the unique identifier of the object in MongoDB (optional on create / insert)

The URI path must have exactly three segments. Anything else will cause an IOException on a load() or save().

Create

When inserting a new object into MongoDB, the id segment of the URI is optional and typically the empty string. By default, MongoDB assigns a unique ID to an object when it is inserted into the database. In this mode, the URI of the EMF resource is automatically updated to include the MongoDB generated ID value. Going back to the example in the Quickstart, the resource URI will be similar to mongo://localhost/app/users/4d6dc268b03b0db29961472c after the call to save() on line 14.

It is also possible for the client to generate the ID and persist the object to MongoDB using that ID. The ID can be any string value that is unique within the MongoDB collection. The quickstart example above would be modified as follows:

Resource resource = resourceSet.createResource(URI.createURI("mongo://localhost/app/users/1"));
resource.getContents().add(user);

try
{
  resource.save(null);
}
catch(IOException e)
{
  e.printStackTrace();
}

Retrieve

To retrieve an object from MongoDB, you load an EMF Resource using the unique URI for the object.

ResourceSet resourceSet = new ResourceSetImpl();
EList uriHandlers = resourceSet.getURIConverter().getURIHandlers();
uriHandlers.add(0, new MongoDBURIHandlerImpl());

Resource resource = resourceSet.getResource(URI.createURI("mongo://localhost/app/users/4d6dc268b03b0db29961472c"), true);
Person user = (Person) resource.getContents().get(0);

Update

To update an object in MongoDB, you simply save the Resource containing the object.

user.setEmail("mongo-emf@example.org);

try
{
  user.eResource().save(null);
}
catch(IOException e)
{
  e.printStackTrace();
}

Delete

To delete an object in MongoDB, you call delete() on the Resource containing the object.

try
{
  user.eResource().delete(null);
}
catch(IOException e)
{
  e.printStackTrace();
}

Collections

A collection of objects may be stored (contained) within a parent object, or stored as individual objects in a MongoDB collection. For objects that are contained as part of a parent object, when you operate on (load, save) the parent object, you operate on (load, save) the entire collection. When a collection is stored as individual objects in a MongoDB collection, each object is contained its own EMF Resource and must be managed individually by the client. If you allow MongoDB to generate the object ID, you may bulk insert a collection of objects in a single save() call. The resource is modified to contain a single Result result object with a proxy to each of the inserted objects. You may iterate over the proxies to load each object into its own Resource. Here is an example of bulk insert:

ResourceSet resourceSet = new ResourceSetImpl();
EList uriHandlers = resourceSet.getURIConverter().getURIHandlers();
uriHandlers.add(0, new MongoDBURIHandlerImpl());

Resource resource = resourceSet.createResource(URI.createURI("mongo://localhost/app/users/"));

for(int i = 0; i < 10; i++)
{
  Person user = ModelFactory.eINSTANCE.createMyObject()
  user.setName("User " + 1);
  user.setEmail("user" + i + "@example.org");
  resource.getContents().add(user);
}

try
{
  resource.save(null);
}
catch(IOException e)
{
  e.printStackTrace();
}

Result result = resource.getContents().get(0);

for(EObject eObject : result.getValues()
{
  Person user = (Person) eObject;
  System.out.println("Person " + user.getName() + " has URI: " + user.eResource.getURI());
}

EMF References

The way in which EMF references are persisted in MongoDB depends on the settings you specified when you created your EMF Ecore and Generator models. Two Ecore settings that affect persistence are: Containment, and Resolve Proxies. The Generator setting that affects persistence is: Containment Proxies. There are three types of references to consider: non-containment, containment, and bi-directional cross-document containment.

Non-containment References

A non-containment reference is modeled by setting Containment = false in the Ecore model. A non-containment reference can be to any other object in the database, a file, or on some other server. The target object may be contained by the referencing object, or could be in some other resource. Non-containment references are always persisted as a proxy. If the target object is in a separate resource from the referencing object, the target object must be persisted, on creation, before the object with the reference so that the proxy URI contains the ID of the target object.

Containment References

A containment reference is modeled by setting Containment = true in the Ecore model. A containment reference is persisted as a nested object in the same MongoDB document as the referencing object if Resolve Proxies = false in the Ecore model or Containment Proxies = false in the Generator model. If Resolve Proxies = true in the Ecore model and Containment Proxies = true in the Generator model, the reference will be persisted as a proxy if the target object is contained in its own Resource (cross-document containment). If the target object is not contained in its own Resource, it will be persisted as a nested object of the referencing object.

Bi-directional Cross-document Containment References

Bi-directional cross-document containment references need special consideration when it comes to saving the objects. For the proxies to be properly persisted, three calls to save() must be made on creation. One of the two objects must be saved twice. The other object must be saved once between the two saves to the other object. For example, consider a bi-directional reference between a Person and an Address, the code to save the two objects would be as follows:

user.setAddress(address);

try
{
  address.save(null);
  user.save(null);
  address.save(null);
}
catch(IOException e)
{
  e.printStackTrace();
}

Modeling Restrictions

There is one minor restriction that you must follow when creating your EMF Ecore model. The following keys are reserved for internal use and may not be used as attribute or reference names:

_id
_eId
_eClass
_timeStamp
_eProxyURI

Mongo EMF Project Bundles

The project consists of several core bundles, an example project, a JUnit test bundle, and a JUnit test utility bundle.

org.eclipselabs.emf.query – this bundle contains the model query support
org.eclipselabs.mongo – this bundle contains an IMongoDB OSGi service that provides basic connectivity to a MongoDB database
org.eclipselabs.mongo.emf – this bundle contains the MongoDBURIHandlerImpl that provides EMF persistence to MongoDB
org.eclipselabs.mongo.freemarker – this bundle contains support for persisting FreeMarker templates in MongoDB
org.eclipselabs.mongo.emf.examples – this bundle contains a simple example using MongoDBURIHandlerImpl
org.eclipselabs.mongo.emf.junit – this bundle contains the JUnit tests for the core bundles
org.eclipselabs.mongo.junit – this bundle contains utilities for users developing their own JUnit tests

Unit Testing

The org.eclipselabs.mongo.junit bundle contains two useful classes that can make writing your unit tests easier.

MongoDatabase

This class is a JUnit @Rule that will clear your MongoDB database after each test. The rule requires the BundleContext and the name of the database to be passed as parameters to its constructor. Here is an example on how to use that rule:

	@Rule
	public MongoDatabase database = new MongoDatabase(Activator.getInstance().getContext(), "junit");

MongoUtil

This utility class contains functions for creating a ResourceSet, getting one or more objects from the database, getting the ID of an object, registering the IMongoDB service with OSGi, and comparing two EObjects. This class has extensive JavaDoc comments that explain the usage of each function.

Launch Configurations

Your launch configuration must include the following bundles and their dependencies:

org.eclipselabs.emf.query
org.eclipselabs.mongo
org.eclipselabs.mongo.emf
org.eclipse.equinox.ds (or equivalent)

The org.eclipselabs.mongo bundle uses OSGi declarative services to register the IMongoDB service. This service is used by MongoDBURIHandlerImpl to connect to MongoDB.

References

Rational Team Concert 3.0 on OS X

Bryan Hunt — Mon, 29 Nov 2010 14:00:10 +0000

Update 4/19/2011: The server zips are back and you no longer have to install on linux and move to OS X.

Rational Team Concert 3.0 is a nice development tool built on Eclipse that runs just fine on Mac OS X even though it’s not officially supported. This guide will help you install and configure RTC 3.0 on OS X. The client is very easy to install. The server used to be easy to install, but some recent changes in the RTC builds has made it much more difficult. Basically, you install the server on Linux, and transfer it to your OS X box.

Installing RTC 3.0 Server on Linux

Since the RTC Server is no longer available as a zip download, you must install the server on a supported platform such as Linux. Once the server is installed, you can transfer the content to OS X and it will just work.

Fire up a Linux box, Parallels, or VMWare (I use Parallels with Ubuntu)
Head over to https://j azz.net/downloads and select Rational Team Concert
Select Linux x86-32/64 for your platform and click Download Rational Team Concert
After logging and accepting the the terms, RTC-Web-Installer-Linux-3.0.zip will be downloaded
Unzip the archive into a folder and run launchpad.sh
Uncheck Install in a shared location for multiple users
Click Jazz Team Server and CCM Application under Install the Server
The Installation Manager will start – login with your jazz.net id and password
Click Next
Agree to the license and click Next
Keep the default directory locations and click Next
Keep the default installation directory and click Next
Select the desired translations and click Next
Click Next
Select Not upgrading from previous product release and click Next
Click Install
After the server is installed, click Finish

Moving RTC Server to OS X

Transfer the contents of the JazzTeamServer directory to OS X. Here is the method I used:

cd ~/IBM
zip -r jazz.zip JazzTeamServer
Copy jazz.zip to your OS X box (I use a Parallels shared folder)
unzip jazz.zip into the directory of your choice (I use /Library)
cd JazzTeamServer/server
rm -rf jre

Configuring RTC Server

You configure the RTC 3.0 Server as you would for any other platform. If you are using OS X Server and want to set up LDAP authentication, skip that configuration during the setup. The setup wizard will not configure it correctly for OS X. I have instructions below on how to configure the Tomcat JNDI realm by hand below.

./server.startup
Point your web browser to https://localhost:9443/jts/setup
Login id: ADMIN password: ADMIN
Click Next
Set the Public URI Root to https://:9443/jts (where is the hostname of your system)
Click Test Connection and then click Next
Keep the default Derby database settings and click Next
Set up Email Notification as desired and click Next
Set up your account and click Next
Click Register Applications and click Next
Keep the default URI, click Test Connection and click Next
Keep the default Derby configuration and click Next
Click Finalize Application Setup and click Next
Click Finish
(Optional) Set up LDAP for use with OS X Server
- ./server.shutdown
- edit tomcat/conf/server.xml
- Disable the database realm
- Configure the JNDI realm as shown below
- ./server.startup

Install your license as you normally would

You should now have a functional server. If you are using OS X Server, remember that the LDAP groups are case sensitive, so make sure you create a JazzUsers group and not a jazzusers group.

Starting RTC Server on Boot

If you would like the RTC Server automatically started when OS X boots, put the following in /Library/LaunchDaemons/com.ibm.rtc.plist




  Label
  com.ibm.rtc
  OnDemand
  
  Program
  server.startup
  AbandonProcessGroup
  
  RunAtLoad
  
  WorkingDirectory
  /Library/JazzTeamServer/server

At the command prompt: sudo launchctl load com.ibm.rtc.plist

Installing RTC Client on OS X

Installing the client on OS X is super simple using the P2 repository.

From the All Downloads tab on jazz.net, scroll down to the section containing the zips and download the P2 Install Repository
unzip the downlaod
From the Eclipse IDE, choose Help -> Install New Software …
Add the directory to the unzipped P2 repository
Check Rational Team Concert and install using the wizard

Configuring OSGi Services with Apache Web Console and Metatype

Bryan Hunt — Wed, 07 Jul 2010 14:30:41 +0000

Introduction

OSGi services can be easily configured using the ConfigurationAdmin service. If you add metadata to your services, they can be configured with a nice user interface such as the Apache Web Console. This can be a very nice way to configure remote servers. This tutorial will walk you through the steps to create the metadata, set up the web console, and configure your services. Here’s an example of the end result where an OSGi service is configured with the Apache Web Console:

Metatype

Administrative tools such as the Apache Web Console can provide a nice form based user interface for configuring your OSGi services only if you provide sufficient metadata for your service properties. Using this metadata, the Apache Web Console knows how to display, for example, a label for each property, display a text box for simple string data, and display a combo box for choosing a value from a list. This metadata is defined using the OSGi Metatype Service.

There are two ways to provide metatype data: an XML file, or by registering a MetaTypeProvider as an OSGi service. Specifying your metatype data in an XML file works well as long as your data is static, and you are not using declarative services. If you need to specify dynamic metatype data such as the values for options, you must register a provider. Metatype will not – yet – work with declarative services. I’ll discuss this in detail in the section below on declarative services. The metatype service allows you to specify the following datatypes for configuring your services:

boolean
byte
char
double
float
int
long
short
String

You can also specify a cardinality for arrays, default values, and label/value pairs for choices.

Metatype XML File

To specify your metatype data in an XML file, you must create an OSGI-INF/metatype/ directory in your bundle. In this directory, you may place one or more XML files adhering to the metatype XML schema. The file contains a number of object class definitions each with a number of attribute definitions. You then specify a designate to tie an object class definition to a service PID. Here is a simple example of a metatype XML file that allows a service to be configured with a property called choice with the possible values: normal and priority.

Metatype Provider

To register a metatype provider, create a class that implements MetaTypeProvider and construct instances of ObjectClassDefinition and AttributeDefinition. The provider can be registered in your bundle activator, or as a declarative service. The metatype specification provides interfaces for the datatypes, but not implementations. You must provide your own implementation of the interfaces, or you may use the EMF implementation I have hosted at Eclipse Labs. Here is the source code that specifies the same configuration metadata as the XML file above using the EMF implementation.

public class ExampleDeclarativeServiceMetatype implements MetaTypeProvider
{
	@Override
	public ObjectClassDefinition getObjectClassDefinition(String id, String locale)
	{
		ObjectClassDefinitionImpl ocd = MetatypeFactory.eINSTANCE.createObjectClassDefinitionImpl();
		ocd.setID("org.eclipselabs.metatype.examples.service");
		ocd.setName("Declarative Service");
		ocd.setDescription("Example Description");

		AttributeDefinitionImpl ad = MetatypeFactory.eINSTANCE.createAttributeDefinitionImpl();
		ad.setName("Exampel Chioce Attribute");
		ad.setDescription("Attribute Description");
		ad.setID("choice");
		ad.setType(AttributeDefinition.STRING);
		ad.setOptionLabels(new String[] {"Normal", "Priority"});
		ad.setOptionValues(new String[] {"normal", "priority"});
		ad.setDefaultValue(new String[] {"normal"});

		ocd.getAttributeDefinitions().add(ad);
		return ocd;
	}

	@Override
	public String[] getLocales()
	{
		return null;
	}
}

Now that you have seen how easy it is to specify your metatype data, lets write some services and configure them using the web console. We start by setting up our target platform.

Target Platform

Setting up your target platform is really easy with Eclipse and PDE. Before you configure Eclipse, you need to download the Apache Web Console (Full) bundle since they do not build P2 repositories. As of this writing, the latest version of the web console is 3.1.0.

Start up Eclipse (I’m using Helios) with a new workspace.
Select Preferences -> Plug-in Development -> TargetPlatform
Click Add…
Select Nothing: Start with an empty target definition
Click Next
Name: Equinox
In the Locations tab, click Add…
Choose Software Site and click Next
Work with: Helios – http://download.eclipse.org/releases/helios
Expand EclipseRT Target Platform Components
Check
1. EMF – Eclipse Modeling Framework SDK
2. Equinox Target Components
Click Finish
Click Add…
Choose Software Site and click Next
Work with: http://metatype-emf-model.eclipselabs.org.codespot.com/hg/site/org.eclipselabs.metatype.site/
Check Metatype EMF Model
Click Finish
Click Add…
Choose Directory and click Next
Location: is the path to the directory containing the web console bundle
Click Finish

Your New Target Definition should look like:

Click Finish, check the target definition to make it active, and click OK. Your target platform is now ready for you to start writing code.

Managed Services

There are two interfaces that can be registered to make your service configurable by ConfigurationAdmin: ManagedService and ManagedServiceFactory. Use these interfaces for non-factory and factory services respectively. Let’s create an Eclipse plug-in project with a ManagedService and ManagedServiceFactory. Here is the code for the ManagedService:

package org.eclipselabs.metatype.examples;

import java.util.Dictionary;
import java.util.Enumeration;

import org.osgi.service.cm.ConfigurationException;
import org.osgi.service.cm.ManagedService;

public class ExampleManagedService implements ManagedService
{
	@SuppressWarnings({ "rawtypes", "unchecked" })
	@Override
	public void updated(Dictionary properties) throws ConfigurationException
	{
		System.out.println("Updating configuration properties for ExampleManagedService");

		if (properties != null)
		{
			Enumeration keys = properties.keys();

			while (keys.hasMoreElements())
			{
				String key = keys.nextElement();
				System.out.println(key + " : " + properties.get(key));
			}
		}
	}
}

The code for the ManagedServiceFactory is almost identical:

package org.eclipselabs.metatype.examples;

import java.util.Dictionary;
import java.util.Enumeration;

import org.osgi.service.cm.ConfigurationException;
import org.osgi.service.cm.ManagedServiceFactory;

public class ExampleManagedServiceFactory implements ManagedServiceFactory
{
	@Override
	public String getName()
	{
		return "ManagedServiceFactoryExample";
	}

	@Override
	@SuppressWarnings({ "rawtypes", "unchecked" })
	public void updated(String pid, Dictionary properties) throws ConfigurationException
	{
		System.out.println("Updating configuration properties for ExampleManagedServiceFactory " + pid);

		if (properties != null)
		{
			Enumeration keys = properties.keys();

			while (keys.hasMoreElements())
			{
				String key = keys.nextElement();
				System.out.println(key + " : " + properties.get(key));
			}
		}
	}

	@Override
	public void deleted(String pid)
	{
		System.out.println("ExampleManagedServiceFactory deleted(" + pid + ")");
	}
}

Create a bundle activator to register the two services:

package org.eclipselabs.metatype.examples;

import java.util.Hashtable;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.Constants;
import org.osgi.service.cm.ManagedService;
import org.osgi.service.cm.ManagedServiceFactory;

public class Activator implements BundleActivator
{
	private static BundleContext context;

	static BundleContext getContext()
	{
		return context;
	}

	public void start(BundleContext bundleContext) throws Exception
	{
		Activator.context = bundleContext;

		Hashtable serviceProperties = new Hashtable();
		serviceProperties.put(Constants.SERVICE_PID, "org.eclipselabs.metatype.examples.managedService");
		context.registerService(ManagedService.class.getName(), new ExampleManagedService(), serviceProperties);

		Hashtable serviceFactoryProperties = new Hashtable();
		serviceFactoryProperties.put(Constants.SERVICE_PID, "org.eclipselabs.metatype.examples.managedServiceFactory");
		context.registerService(ManagedServiceFactory.class.getName(), new ExampleManagedServiceFactory(), serviceFactoryProperties);
	}

	public void stop(BundleContext bundleContext) throws Exception
	{
		Activator.context = null;
	}
}

Now, we need the metatype data for the two services. In your plug-in project, create the directory OSGI-INF/metatype/ and in that directory, create the following two files:

managed_service.xml

managed_service_factory.xml

Note that for the factory case, you must specify both the pid and factoryPid in the metatype XML.

Run the Examples

Let’s set up a launch configuration and run the examples you’ve created so far.

Select Run -> Run Configurations…
Select OSGi Framework
Click New launch configuration on the toolbar
In the Bundles tab, click Deselect All
Uncheck Include optional dependencies when computing required bundles
Check your examples bundle
Check the following bundles from the Target Platform
1. org.eclipse.equinox.metatype
2. org.eclipselabs.metatype
3. org.eclipse.equinox.cm
4. org.ecliplse.equinox.http.jetty
5. org.mortbay.jetty.server
6. org.mortbay.jetty.util
7. org.apache.felix.webconsole
Click Add Required Bundles
On the Arguments tab, add the VM arguments: -Dorg.osgi.service.http.port=8080

Your launch configuration should look like:

Click Run and after the application starts, open your web browser on the URL: http://localhost:8080/system/console/configMgr. When prompted for login, use admin for both the id and password. You should now see the Apache Felix Web Console with your services listed for configuration. Your services will probably appear twice, and if you click to edit them you will see different results. One will display an empty text box, and the other will display a proper form with a combo allowing you to select between Normal and Priority. Ignore the one with the empty text box – I assume it’s a bug in the web console. For your managed service, you can click the edit button to change it’s configuration. For your managed service factory, you can add and remove configurations.

Try changing the the setting on your managed service from Normal to Priority. You should see the following in the Console view:

Declarative Services

As I mentioned above, the metatype service does not – yet – work with declarative services. With some help from Tom Watson, I proposed a change to the OSGi specification to allow the metatype service to work with declarative services. Here are the important parts of the proposal:

I would propose changing the MetaType spec to allow for MetaTypeProvider
services to be registered without a ManagedService or ManagedServiceFactory,
and with the following two service properties: metatype.target.pid, and
metatype.factory. The value of metatype.target.pid would be set to the pid of
the declarative service for which the meta type applies, and the
metatype.factory would be set to boolean true if the pid is a factory pid, and
false otherwise.

The meta type service would be changed to include a service tracker for
MetaTypeProvider and the existence of the two properties defined above. The
meta type service would continue to look for ManagedService and
ManagedServiceFactory and simply add any MetaTypeProvider services with those
properties to the list.

Tom suggested that we use metatype.provider.pid and metatype.provider.type = “normal” | “factory” instead of metatype.target.pid and metatype.factory. The net of this is that you can register a metatype provider with the metatype.provider.pid and metatype.provider.type properties set, and you will get metatype data for declarative services. This proposal appears to be moving forward into the OSGi specification.

I have provided a patch to the Equinox metatype implementation at https://bugs.eclipse.org/bugs/show_bug.cgi?id=311128 with these proposed changes. With this patch, you can experiment with metatype and declarative services. Note that this work is not final and still subject to change until it is in the actual OSGi specification. To try this out, you first need the Equinox metatype source from CVS.

Switch to the CVS Repository Exploring perspective
Click Add CVS Repository in the toolbar
Host: dev.eclipse.org
Repository path: /cvsroot/rt
User: anonymous
Connection type: pserver
Click Finish
In the CVS Repositories view, expand:
1. /cvsroot/rt
2. HEAD
3. org.eclipse.equinox
4. compendium
5. bundles
Select org.eclipse.equinox.metatype, right-click and choose Check Out

You should now have the metatype source in your workspace ready to be patched. To apply my patch:

Switch back to the Plug-in Development perspective
Right-click on the org.eclipse.equinox.metatype project
Choose Team -> Apply Patch…
Choose URL https://bugs.eclipse.org/bugs/attachment.cgi?id=166704
Click Finish

Let’s create a declarative service and try this out. You need to create a new bundle for your declarative services. If you add your declarative service metatype provider to a bundle that contains metatype XML files, the registered metatype providers are ignored. This might be a bug in the metatype implementation.

Here is the code for the declarative service:

package org.eclipselabs.metatype.examples.ds;

import java.util.Dictionary;
import java.util.Enumeration;

import org.osgi.service.component.ComponentContext;

public class ExampleDeclarativeService
{
	@SuppressWarnings({ "rawtypes", "unchecked" })
	protected void activate(ComponentContext context)
	{
		System.out.println("Activating ExampleDeclarativeService");

		Dictionary properties = context.getProperties();

		if (properties != null)
		{
			Enumeration keys = properties.keys();

			while (keys.hasMoreElements())
			{
				String key = keys.nextElement();
				System.out.println(key + " : " + properties.get(key));
			}
		}
	}

	protected void deactivate()
	{
		System.out.println("Deactivating ExampleDeclarativeService");
	}
}

Here is the code for the declarative service metatype:

package org.eclipselabs.metatype.examples.ds;

import org.eclipselabs.metatype.AttributeDefinitionImpl;
import org.eclipselabs.metatype.MetatypeFactory;
import org.eclipselabs.metatype.ObjectClassDefinitionImpl;
import org.osgi.service.metatype.AttributeDefinition;
import org.osgi.service.metatype.MetaTypeProvider;
import org.osgi.service.metatype.ObjectClassDefinition;

public class ExampleDeclarativeServiceMetatype implements MetaTypeProvider
{
	@Override
	public ObjectClassDefinition getObjectClassDefinition(String id, String locale)
	{
		ObjectClassDefinitionImpl ocd = MetatypeFactory.eINSTANCE.createObjectClassDefinitionImpl();
		ocd.setID("org.eclipselabs.metatype.examples.service");
		ocd.setName("Declarative Service");
		ocd.setDescription("Example Description");

		AttributeDefinitionImpl ad = MetatypeFactory.eINSTANCE.createAttributeDefinitionImpl();
		ad.setName("Exampel Chioce Attribute");
		ad.setDescription("Attribute Description");
		ad.setID("choice");
		ad.setType(AttributeDefinition.STRING);
		ad.setOptionLabels(new String[] {"Normal", "Priority"});
		ad.setOptionValues(new String[] {"normal", "priority"});
		ad.setDefaultValue(new String[] {"normal"});

		ocd.getAttributeDefinitions().add(ad);
		return ocd;
	}

	@Override
	public String[] getLocales()
	{
		return null;
	}
}

Here is the code for the declarative service factory metatype:

package org.eclipselabs.metatype.examples.ds;

import java.util.UUID;

import org.eclipselabs.metatype.AttributeDefinitionImpl;
import org.eclipselabs.metatype.MetatypeFactory;
import org.eclipselabs.metatype.ObjectClassDefinitionImpl;
import org.osgi.service.metatype.AttributeDefinition;
import org.osgi.service.metatype.MetaTypeProvider;
import org.osgi.service.metatype.ObjectClassDefinition;

public class ExampleDeclarativeServiceFactoryMetatype implements MetaTypeProvider
{
	@Override
	public ObjectClassDefinition getObjectClassDefinition(String id, String locale)
	{
		ObjectClassDefinitionImpl ocd = MetatypeFactory.eINSTANCE.createObjectClassDefinitionImpl();
		ocd.setID("org.eclipselabs.metatype.examples.service.factory");
		ocd.setName("Declarative Service Factory");
		ocd.setDescription("Example Description");

		AttributeDefinitionImpl ad = MetatypeFactory.eINSTANCE.createAttributeDefinitionImpl();
		ad.setName("Exampel Chioce Attribute");
		ad.setDescription("Attribute Description");
		ad.setID("choice");
		UUID normal = UUID.randomUUID();
		UUID priority = UUID.randomUUID();
		ad.setType(AttributeDefinition.STRING);
		ad.setOptionLabels(new String[] {"Normal", "Priority"});
		ad.setOptionValues(new String[] {normal.toString(), priority.toString()});
		ad.setDefaultValue(new String[] {normal.toString()});

		ocd.getAttributeDefinitions().add(ad);
		return ocd;
	}

	@Override
	public String[] getLocales()
	{
		return null;
	}
}

The metatype providers can be registered as declarative services. When you register them, you must set the metatype.provider.pid and metatype.provider.type properties. First, register the declarative service as a factory and non-factory configurable service.

Here is the non-factory registration:

Here is the factory configurable service:

Here is the metatype provider registration:

Here is the metatype factory provider registration:

That’s all the code we need, so let’s modify our launch configuration and try it out.

Run the Examples

Bring up the launch configuration you created to run the first example.

Add your new bundle containing your declarative services
Add the org.eclipse.equinox.metatype bundle from your Workspace
Add the org.eclilpse.equinox.ds bundle
Remove the org.eclipse.equinox.metatype bundle from the Target Platform
Click Add Required Bundles

Your launch configuration should look like:

Click Run and point your web browser to http://localhost:8080/system/console/configMgr. You should see your declarative services in addition to your managed services. Try creating a configuration for your factory service and you will see it display the value of the UUID that was dynamically chosen for a configuration value. This is where the real power of this technology shines – the ability to programatically create values for declarative service configuration and have those values available as choices on an administrative UI.

If you don’t feel like setting up the bundles and typing in the code, you can get the example source code from Eclipse Labs.