OSGi Configuration Admin requires AUXILIARY objectclasses

• Key: DIRSERVER-656
• Type: Bug
• Status: Closed
• Resolution: Later
• Priority: Major
• Assignee: Enrique Rodriguez
• Reporter: John Conlon
• Affects Version/s: 1.5.1
• Fix Version/s: 1.5.1

Description

The OSGi Configuration Admin service requires the two objectclasses, apacheServiceConfiguration and apacheFactoryConfiguration specified in apache.schema be changed to tagging (AUXILIARY) objectclasses.

Comments

[John Conlon]

Changes objectclasses associated with the OSGi Configuration Admin implementation from Structural to Auxiliary.

[John Conlon]

The OSGi Configuration Admin implementation will be required to support standard OSGi configuration attributes. Many of these attributes include a period in their name. (like service.pid, event.topics, event.filter, etc). If these standard attributes are not 'built in' to the ApacheDS OSGi Admin (and specified as schemas) end users will be forced to not only create their own schemas but implement their own org.osgi.service.cm.ConfigurationPlugin implementations to support mapping them from LDAP attributes.

Proposal:
 1. The existing OSGi objectclasses apacheServiceConfiguration, apacheFactoryConfiguration and their attributes be defined in a schema file seperate from apache.schema. (named osgi.schema?)
 2. Top level oids be assigned for osgi objectclasses and attributes.
 3. Assign standard tagging (auxiliary) objectclasses for typical component functionality. For example an eventhandler objectclass would be specified to model a component that implements EventHandler. It would contain event.topics property and may contain an event.handler property.
 4. A base org.osgi.service.cm.ConfigurationPlugin would be delivered as part of the Configuration Admin service to map osgi specific ldap attributes to standard osgi attributes.

[Emmanuel Lecharny]

Just a concern about this issue status : why is it marked as a bug, instead of a task?

[John Conlon]

Considered the previous use of structural objectclasses and extentsibleObjects as preventing users of graphical browsers from working with Config Admin.

Perhaps it could also be labeld a task or improvement?

[John Conlon]

This fix is still necessary.

[Emmanuel Lecharny]

This is for 1.5.0, at least (may be later)

Is this in the works or has it been taken care of already? Shall we push to 1.5.1 ?

[Enrique Rodriguez]

This is still a valid issue, but after recent discussions on OSGi prioritization, I have pushed it to 1.5.1. I'll make sure the issue is included in the OSGi plan.

[Alex Karasulu]

Closing this as something to be considered later since the OSGi direction has slowed down.