You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Actions

For the Object Repositories two interfaces are currently defined:

  • Repository interface, that users can talk to to checkout and commit versions.
  • RepositoryReplication interface, that is used by the replication mechanism.

Repository

A couple of methods are defined for this interface:

  • query() - returns a sorted set of ranges describing the versions available in the repository;
  • checkout(version) - checks out the specified version of the repository;
  • commit(updatedConfiguration, fromVersion) - commits a new version, in case the fromVersion was the most recent version still in the repository. If not, false is returned to indicate a conflict occurred.

We will leave out updating (as in Subversion), as the first concern is to have the basic functionality working before focusing on other issues/functionality.

A version is defined as a long, as that allows us to have enough versions. The data that is checked out, or committed, can be seen as a "blob" and will be a passed on as stream, as that provides us with the freedom to decide later on what will be in the repository exactly (or at least the format in which it will be).

RepositoryReplication

Replicating the repositories is similar to the normal repository functionality.

It adds the methods:

  • query() - returns a sorted set of ranges describing the versions available in the repository;
  • get(version) - get the specified version of the repository;
  • put(configuration, version) - store the configuration as the specified version.

There is no functionality to get/put multiple versions at once, because once there is a stream which contains several versions there is no way to split them up again. The only way to do that is to determine the size of the stream, but then we have to have read it first.

Gaining access to the Repository service(s)

The repositories will be created by using the ManagedServiceFactory. This allows us to create services, that are not bound to specific bundles (as with the normal ServiceFactory), and we can provide each repository with properties we need to identify it. Each repository will at least need properties like customer, name (grouping, license or version) and optionally something like a region or other customer specific properties.

All properties will be made available via ConfigurationAdmin. The customer, name tuple will be an unique id for a repository, but does not necessarily tell everything about the repository.

Retrieval of the Repository services can be done quite easily, by using the getServiceReferences(clazz, filter) method that is available on the BundleContext. Defining a class combined with a filter makes it possible to get ie. all repositories for a client, of a specific type (or whatever filtering you would like to apply). Filtering is defined in 3.2.6 of the OSGi core spec, and using these Filters allows us to filter on the Dictionary of properties that is provided to every repository by ConfigAdmin.

  • No labels