A Deployment Package can contain one or more Autoconf resources. The Manifest of the Deployment Package connects this resource to the Autoconf Resource Processor. When the Deployment Package is deployed, the Autoconf Resource Processor reads the information from the Autoconf resources and creates Configuration objects: both Managed Service as well as Managed Service Factory Configuration objects.

When the Deployment Package is updated or uninstalled, the Autoconf Resource Processor must delete the appropriate Configuration objects.

Factory configurations can be created and deleted any number of times. This concept of multiplicity makes it straightforward to associate factory configurations with a Deployment Package. Each Deployment Package can create its unique configurations that are independent of any other Deployment Packages. When the Deployment Package is uninstalled, the created configurations can be deleted without any concern for sharing.

A factory configuration is defined in a Designate element. The factoryPid must be set to the PID of the related Managed Service Factory service. For example:

 <Designate pid="a" factoryPid="com.acme.a"
                bundle="osgi-dp:com.acme.A">
    <Object ocdref="a">
        <Attribute adref="foo" content="Zaphod Beeblebrox"/>
    </Object>
 </Designate>

The Autoconf resource cannot use the actual PID of the Configuration object because the Configuration Admin service automatically generates the PID of factory configurations. This created PID is called the actual PID.

The Autoconf resource author cannot know the actual PID ahead of time. The Autoconf resource must therefore specify a alias. The alias does not have to be globally unique; it must only be unique for a specific Autoconf resource. The Autoconf Processor must maintain the following association (per Autoconf resource):

 alias → actual PID

The alias can be viewed as an Autoconf resource local name for the factory configuration PID. The actual PID is generated when the Autoconf processor creates a new factory configuration. This mapping is identical to the mapping defined for the Configuration Admin Plugin.

The alias → actual PID association must be used by the Autoconf Processor to decide what life cycle operation to execute.

Uninstalling an Autoconf resource requires that the Autoconf Resource Processor deletes all Configuration objects associated with the resource.

A singleton configuration is associated with a Managed Service. The Autoconf Resource Processor must only use singleton configurations for bundles that are contained in the same Deployment Package as the Autoconf resource. The target Deployment Package can provide a list of these bundles.

This ownership policy is required to prevent sharing conflicts. For this reason, the bundle attribute in the Designate element must be set to the location of the bundle so that this ownership is enforced by the Configuration Admin service. The location of the bundle is defined by the Bundle Symbolic Name of the given bundle prefixed with osgi-dp:.

The processing must abort with a fatal error if the bundle attribute is not set. The Autoconf Resource processor must bind the singleton configuration to the given bundle.

If a singleton configuration with a given PID already exists, it must be unbound or bound to the same location contained by the bundle attribute. Otherwise the processing must abort.

The singleton configuration must be merged with or replaced by the information in the Object element, depending on the merge attribute as described in Assigning a Value.

For example, bundle A uses a factory configuration with the factory PID com.acme.a and bundle B uses a singleton configuration with PID com.acme.b. They define the following configuration properties:

com.acme.a:
gear            Integer
ratio           Vector of Float

com.acme.b:
foo             String
bar             Short[]

For proper operation, a Deployment Package P needs a configuration for com.acme.a and com.acme.b with the following values:

    gear        = 3
    ratio       = {3.14159,  1.41421356, 6.022E23}
    foo         = "Zaphod Beeblebrox"
    bar         = {1,2,3,4,5}

The corresponding autoconf.xml resource associated with Deployment Package P would look like:

<?xml version="1.0" encoding="UTF-8"?>
<metatype:MetaData 
    xmlns:metatype=
        "http://www.osgi.org/xmlns/metatype/v1.1.0">

  <OCD id="a">
    <AD id="gear"  type="Integer" cardinality="0" />
    <AD id="ratio" type="Float" cardinality="-3" />
  </OCD>

  <OCD id="b">
    <AD id="foo"   type="String" cardinality="0"/>
    <AD id="bar"   type="Short" cardinality="5"/>
  </OCD>

  <Designate pid="x" factoryPid="com.acme.a" 
        bundle="osgi-dp:com.acme.a">
    <Object ocdref="a">
        <Attribute adref="gear" content="3" />
        <Attribute adref="ratio">
            <Value>3.14159</Value>
            <Value>1.41421356"</Value>
            <Value>6.022E23"</Value>
        </Attribute>
    </Object>
  </Designate>

  <Designate pid="com.acme.b"        
        bundle="osgi-dp:com.acme.B">
    <Object ocdref="b">
        <Attribute adref="foo" content="Zaphod Beeblebrox"/>
        <Attribute adref="bar">
            <Value>1</Value>
            <Value>2</Value>
            <Value>3</Value>
            <Value>4</Value>
            <Value>5</Value>
        </Attribute>
    </Object>
  </Designate>
</metatype:MetaData>

The Autoconf resources share a scheme and can cooperate with the Metatype Service Specification. An Autoconf resource primarily contains a number of values for configuration objects in the Designate elements. Designate elements:

Designate elements contain an Object element that contains the actual value. Object elements refer to an OCD element by name. The OCD elements act as a descriptor of the properties.

The OCD elements that are referred from an Object element can be contained in the Autoconf resource, or they can come from the Meta Type service. The reference takes place through the ocdref attribute of the Object element. The Autoconf Resource Processor must first match this name to any OCD elements in the Autoconf resources. If the reference cannot be found in this file, it must consult the Meta Type service (if present) for the bundle that is associated with the PID that is configured.

The Autoconf Processor must create any factory and singleton configurations when it is called with an Autoconf resource. This phase should perform as much validation as possible. The configurations must be created in the order of appearance in the Autoconf resource.

In the commit method, the Autoconf Resource Processor must first delete all Configuration objects that were uninstalled. Thereafter, it must set or update the appropriate Configuration objects.

This ordering implies that a customizer bundle cannot receive configuration parameters from an Autoconf resource.

As described in Configuration Admin Service Specification, it is possible for a malicious bundle to register a Managed Service under a PID used by another (legitimate) bundle. This activity essentially hijacks the Managed Service PID, and constitutes a denial of service attack on the legitimate bundle (as it never receives the configuration information it needs). The Configuration Admin specification describes a location binding technique that can be used to prevent this attack. The Autoconf Resource Processor must bind Configuration objects to locations specified in the Autoconf resources using the mandatory bundle attribute.

The capabilities of an Autoconf Resource Processor must be limited to the permissions that are granted to the signer of a Deployment Package. This is the specified way for the Deployment Admin service to act. The Autoconf Resource Processor does not have to take any special actions; all its actions are automatically scoped by the signer of the Deployment Package.

This restriction implies, however, that the Autoconf Resource Processor must do a doPrivileged method for any actions that should not be scoped: for example, when it persists the associations of the alias → actual PID.

A Deployment Package that requires any activity from the Autoconf Resource processor must at least provide ConfigurationPermission[*,CONFIGURE].