Experimenting with the OSGi Configuration Admin implementation in
Enirique's sandbox/configuration.  Was able to upgrade it to use the
felix service binder and interact with the latest SNAPSHOT apacheds/mina
modules that I OSGi bundlized last week.  (Note: I haven't migrated to
the bundles Enrique committed in the trunks/apacheds/osgi yet.)
Nevertheless the cm bundle appears to be up, listening to the DIT for
events, and offering it's Service for client bundle configuration.

Next step is to add a configuration objectclass entry to the DIT so I
can actually store configurations. Is there a configuration schema
and/or a ConfigurationSchema.java for doing this?

regards,
John

[ Post a follow-up to this message ]

John E. Conlon wrote:
> Experimenting with the OSGi Configuration Admin implementation in
> Enirique's sandbox/configuration.  Was able to upgrade it to use the
> felix service binder and interact with the latest SNAPSHOT apacheds/mina
> modules that I OSGi bundlized last week.  (Note: I haven't migrated to
> the bundles Enrique committed in the trunks/apacheds/osgi yet.)
> Nevertheless the cm bundle appears to be up, listening to the DIT for
> events, and offering it's Service for client bundle configuration.
>
> Next step is to add a configuration objectclass entry to the DIT so I
> can actually store configurations. Is there a configuration schema
> and/or a ConfigurationSchema.java for doing this?

Damn, I had a huge reply explaining this last night and Thunderbird
flashed-out - it's never done that before.  Here it is again.

*** Keep in mind we agreed here, some time ago, to update these services
to OSGi R4 and to move them to Felix, so the SVN location will change.

The short answer is that the attributesType's and objectClass's you are
looking for are in the apache.schema.  We've typically put entries in
the apache.schema until such time as there are enough of them to either
warrant their own schema file or they justify their own OID range.

The standard location for configuration in the DIT is under
ou=configuration,ou=system.  There should be this ou already, by default.

The apacheServiceConfiguration and the apacheFactoryConfiguration
correspond to ManagedService's and ManageServiceFactory's, respectively.
You use these in conjunction with ExtensibleObject objectClass's to
provide custom attributes.

Looking this over now, I would change apacheServiceConfiguration and
apacheFactoryConfiguration from STRUCTURAL objectClass's to AUXILIARY
objectClass's.  Then you could use them as "marker" objectClass's and
add them to any DIT entry you so choose.  CM is going to return a set of
attributes, so the objectClass doesn't matter and I think this would
work and be more flexible.  I would still start searches below
ou=configuration,ou=system.  WDYT?

I've included an example LDIF, below, of using this with the DNS
service.  Using a ManagedServiceFactory is the natural way to handle
multi-homed configurations, where you want to serve 1..n DIT locations
to a specific NIC.  A DNS spec uses the term "catalog":

From RFC 1035:

"... The catalog structure can be an almost static structure that
need change only when the system administrator changes the
zones supported by the server. ..."

Example showing use with a DNS Server Factory:

dn: cn=org.apache.dns. 1,cn=dns,ou=services,ou=configuration,ou
=system
objectClass: apacheServiceConfiguration
objectClass: extensibleObject
cn: org.apache.dns.1
ipAddress: 192.168.0.1
ipPort: 53
baseDn: dc=example,dc=com
apacheServicePid: org.apache.dns.1
apacheServiceFactoryPid: org.apache.dns.factory


Relevant entries in the apache.schema:

attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.15
NAME 'apacheServicePid'
DESC 'A string up to 256 characters in length'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )

attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.16
NAME 'apacheServiceFactoryPid'
DESC 'A string up to 256 characters in length'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )

objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.3
NAME 'apacheServiceConfiguration'
SUP top
STRUCTURAL
MUST ( cn $ apacheServicePid )
MAY ( apacheServiceFactoryPid ) )

objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.4
NAME 'apacheFactoryConfiguration'
SUP top
STRUCTURAL
MUST ( cn $ apacheServicePid ) )

Enrique

[ Post a follow-up to this message ]

Enrique,

Again I'm going to ask you to start sharing some of what you're doing
with the rest of the dev list.  Simply having an esoteric conversation
between you and John is not enough to shed light on what is actually
about to happen.

You need to bring the rest of us to this OSGi party if you're going to
avoid -1 votes.  I already posted an email without getting a response to
this dev list asking you to elaborate.  I have sent several private
reminders to you to start sharing "your" OSGi aims with others.   I even
called you on the phone.  If this conduct does not change, a veto is the
least of your worries.  You're on the PMC, you should know how to engage
this community properly.

Start explaining to the rest of us what is going on so a surprise is not
sprung in the last minute.   Is this so hard?  It takes a few words to
give all a heads up.  I hope you are not thinking you can just jam in
the recent work on OSGi.  You're doing some good work but you're not
acting in accordance with what a community member much less a PMC member
should be doing.

Expose the work being done so others can have a chance to participate.

Alex

Enrique Rodriguez wrote:
> John E. Conlon wrote: 
>
> Damn, I had a huge reply explaining this last night and Thunderbird
> flashed-out - it's never done that before.  Here it is again.
>
> *** Keep in mind we agreed here, some time ago, to update these
> services to OSGi R4 and to move them to Felix, so the SVN location
> will change.
>
> The short answer is that the attributesType's and objectClass's you
> are looking for are in the apache.schema.  We've typically put entries
> in the apache.schema until such time as there are enough of them to
> either warrant their own schema file or they justify their own OID range.
>
> The standard location for configuration in the DIT is under
> ou=configuration,ou=system.  There should be this ou already, by default.
>
> The apacheServiceConfiguration and the apacheFactoryConfiguration
> correspond to ManagedService's and ManageServiceFactory's,
> respectively.  You use these in conjunction with ExtensibleObject
> objectClass's to provide custom attributes.
>
> Looking this over now, I would change apacheServiceConfiguration and
> apacheFactoryConfiguration from STRUCTURAL objectClass's to AUXILIARY
> objectClass's.  Then you could use them as "marker" objectClass's and
> add them to any DIT entry you so choose.  CM is going to return a set
> of attributes, so the objectClass doesn't matter and I think this
> would work and be more flexible.  I would still start searches below
> ou=configuration,ou=system.  WDYT?
>
> I've included an example LDIF, below, of using this with the DNS
> service.  Using a ManagedServiceFactory is the natural way to handle
> multi-homed configurations, where you want to serve 1..n DIT locations
> to a specific NIC.  A DNS spec uses the term "catalog":
>
> From RFC 1035:
>
> "... The catalog structure can be an almost static structure that
>      need change only when the system administrator changes the
>      zones supported by the server. ..."
>
> Example showing use with a DNS Server Factory:
>
> dn: cn=org.apache.dns. 1,cn=dns,ou=services,ou=configuration,ou
=system
> objectClass: apacheServiceConfiguration
> objectClass: extensibleObject
> cn: org.apache.dns.1
> ipAddress: 192.168.0.1
> ipPort: 53
> baseDn: dc=example,dc=com
> apacheServicePid: org.apache.dns.1
> apacheServiceFactoryPid: org.apache.dns.factory
>
>
> Relevant entries in the apache.schema:
>
> attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.15
>     NAME 'apacheServicePid'
>     DESC 'A string up to 256 characters in length'
>     EQUALITY caseIgnoreIA5Match
>     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )
>
> attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.16
>     NAME 'apacheServiceFactoryPid'
>     DESC 'A string up to 256 characters in length'
>     EQUALITY caseIgnoreIA5Match
>     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )
>
> objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.3
>     NAME 'apacheServiceConfiguration'
>     SUP top
>     STRUCTURAL
>     MUST ( cn $ apacheServicePid )
>     MAY ( apacheServiceFactoryPid ) )
>
> objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.4
>     NAME 'apacheFactoryConfiguration'
>     SUP top
>     STRUCTURAL
>     MUST ( cn $ apacheServicePid ) )
>
> Enrique
>
>

[ Post a follow-up to this message ]

On 5/23/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
> Enrique,
>
> Again I'm going to ask you to start sharing some of what you're doing
> with the rest of the dev list.  Simply having an esoteric conversation
> between you and John is not enough to shed light on what is actually
> about to happen.

Yes, I will work to share more of my OSGi work with the dev list.  I
thought that responding publicly to John's question would be a step in
that direction.  Though, again, it was my understanding that it was OK
to move Config Admin to Felix, in which case even less of this
discussion would have taken place here.

I would like to point out that the Configuration Admin service, as the
OSGi standard way to handle dynamic configuration, is very
well-detailed in the OSGi R3 and R4 specifications.  Admittedly, there
are 1100 pages worth of spec but the Config Admin portion is less
than, say, Kerberos' RFC 4120 or X.501.

> You need to bring the rest of us to this OSGi party if you're going to
> avoid -1 votes.  I already posted an email without getting a response to
> this dev list asking you to elaborate.

I'm sorry I didn't respond faster but you have to understand that it
is way less than 24 hrs. from when I checked email.  I responded to
John's question first in an effort to support a pending user request.
I'm now at work, responding to Directory email.

>  I have sent several private
> reminders to you to start sharing "your" OSGi aims with others.   I even
> called you on the phone.  If this conduct does not change, a veto is the
> least of your worries.  You're on the PMC, you should know how to engage
> this community properly.

I apologize for having a bandwidth problem.  As I mentioned in another
post, I expect that as the Felix project stabilizes, I will be able to
focus more time on the Directory project.

I have made a series of announcements, a request here and a couple
announcements on the Felix list:

Directory request:
http://www.archivum.info/dev-aYN4UC...2/msg00192.html

Felix announcements:
http://mail-archives.apache.org/mod...200511.mbox/aj=
ax/%3c43837E9B.90809-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org%3e

http://mail-archives.apache.org/mod...200602.mbox/aj=
ax/%3c43F8AA7E.5000802-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org%3e

This subject was also further discussed on the Felix list at:
http://mail-archives.apache.org/mod...200605.mbox/aj=
ax/%3c44561B8D.9090906-kVkjuGRpcHHz+pZb47iToQ@public.gmane.org%3e

> Start explaining to the rest of us what is going on so a surprise is not
> sprung in the last minute.   Is this so hard?  It takes a few words to
> give all a heads up.  I hope you are not thinking you can just jam in
> the recent work on OSGi.  You're doing some good work but you're not
> acting in accordance with what a community member much less a PMC member
> should be doing.

I do not expect to jam in the OSGi work.  I would not simply merge in
the OSGi work without detailing it first.

> Expose the work being done so others can have a chance to participate.

I'm a bit at a loss here.  I'm pounding away at work and on the Felix
project and I was trying to get a demo together to further the aims of
the Directory project and Felix project at JavaOne.  I've made a
number of announcements on the Directory and Felix projects and I
attemted to answer John's question to the best of my ability, and in a
public forum.  Admittedly, I can do better by focusing more on the
Directory project, but as a zero-sum game it has to come at the
detriment of other projects.

I will work more to bring the rest of the Directory team up-to-speed
on the OSGi integration.

Enrique

[ Post a follow-up to this message ]

Enrique Rodriguez wrote:

>
> *** Keep in mind we agreed here, some time ago, to update these
> services to OSGi R4 and to move them to Felix, so the SVN location
> will change.

Yes I saw a post (on felix maillist?) that you and Richard Hall were
doing an apacheds demo for J1, so I was watching for something to show
up in either the felix or the apacheds repos.

But I didn't wait for it, and instead on my own I bundlized enough of
the backend, mina, and ldap to get a server up and running and talking
with an ldap browser on the oneside and my applications need for jndi
configuration data on the other. I figured I could learn something in
the process, even if I throw my bundles away later.

My bundlizing of the apacheds jars was a painful process as the new
classloading restrictions in Felix and my ignorance of the optimal
grouping of apacheds jars into bundles caused a lot of trial and error
experimentation to determine the import/export declarations in the
bundle manifests. Although my bundles appear to be working I am not sure
if they are completely declaring imports and exports.

BTW - Still waiting for the updated release of maven-osgi-plugin with
Peter Kriens' manifest creation feature to ease or eliminate this
problem. Do you know the status?

By the time I had my osgi apacheds bundles working I noticed your J1
efforts committed to the svn repository. (trunks/apacheds/osgi)

I did a mvn install of the trunks/apacheds/osgi/server-main-osgi and
tried running the apacheds.sh. Had some problems with this but I figured
you may still be working to update/and test these. At this point I
decided to take a look at your configuration admin impl.



> The short answer is that the attributesType's and objectClass's you
> are looking for are in the apache.schema. We've typically put entries
> in the apache.schema until such time as there are enough of them to
> either warrant their own schema file or they justify their own OID
> range.

Yes I see these now. (Replaced my LDAP Browser with JXplorer and now can
see schemas.

> The standard location for configuration in the DIT is under
> ou=configuration,ou=system. There should be this ou already, by
> default.

Yes

> The apacheServiceConfiguration and the apacheFactoryConfiguration
> correspond to ManagedService's and ManageServiceFactory's,
> respectively.
Yes I see these objectClasses as well.
objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.3
>     NAME 'apacheServiceConfiguration'
>     SUP top
>     STRUCTURAL
>     MUST ( cn $ apacheServicePid )
>     MAY ( apacheServiceFactoryPid ) )
>
> objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.4
>     NAME 'apacheFactoryConfiguration'
>     SUP top
>     STRUCTURAL
>     MUST ( cn $ apacheServicePid ) )

> attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.15
>     NAME 'apacheServicePid'
>         DESC 'A string up to 256 characters in length'
>         EQUALITY caseIgnoreIA5Match
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )
>
> attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.16
>     NAME 'apacheServiceFactoryPid'
>         DESC 'A string up to 256 characters in length'
>         EQUALITY caseIgnoreIA5Match
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )
>
Aren't the names for these objectclasses backwards? - Shouldn't the first on
e be called apacheFactoryConfiguration
because it may include an apacheServiceFactoryPid (and a ManageServiceFactor
y) and the second one apacheServiceConfiguration
because it doesn't use a apacheServiceFactoryPid (and thus like a  ManagedSe
rvice)?

The other thing I noticed is that the ConfigurationAdminFactory.updateTarget
ServiceMatching method is
checking for the attributes 'service.pid' and 'service.factoryPid' and not '
apacheServicePid' or
'apacheServiceFactoryPid' and so does not recognize a valid configuration en
try and just returns. Bug?


> You use these in conjunction with ExtensibleObject objectClass's to
> provide custom attributes.
Have not any experience with ExtensibleObject until today. JXplorer does
not seem to know what to do with this. Can it be used with visual
editors to add arbitrary valid attributes?

Can ExtensibleObject be used to add invalid attributes? (Ones undefined
in the schema? Like the ones in your ldif example below?)

> Looking this over now, I would change apacheServiceConfiguration and
> apacheFactoryConfiguration from STRUCTURAL objectClass's to AUXILIARY
> objectClass's. Then you could use them as "marker" objectClass's and
> add them to any DIT entry you so choose.
Yes this is a good idea.

> CM is going to return a set of attributes, so the objectClass doesn't
> matter and I think this would work and be more flexible. I would still
> start searches below ou=configuration,ou=system. WDYT?
Sounds okay. But I noticed JndiConfigurationStore has a
"cm.entry.basedn" property for customizing it.


> I've included an example LDIF, below, of using this with the DNS
> service. Using a ManagedServiceFactory is the natural way to handle
> multi-homed configurations, where you want to serve 1..n DIT locations
> to a specific NIC. A DNS spec uses the term "catalog":
> From RFC 1035:
>
> "... The catalog structure can be an almost static structure that
>      need change only when the system administrator changes the
>      zones supported by the server. ..."
>
> Example showing use with a DNS Server Factory:
>
> dn: cn=org.apache.dns. 1,cn=dns,ou=services,ou=configuration,ou
=system
> objectClass: apacheServiceConfiguration
> objectClass: extensibleObject
> cn: org.apache.dns.1
> ipAddress: 192.168.0.1
> ipPort: 53
> baseDn: dc=example,dc=com
> apacheServicePid: org.apache.dns.1
> apacheServiceFactoryPid: org.apache.dns.factory

regards,
John

[ Post a follow-up to this message ]

John E. Conlon wrote:
...
> My bundlizing of the apacheds jars was a painful process as the new
> classloading restrictions in Felix and my ignorance of the optimal
> grouping of apacheds jars into bundles caused a lot of trial and error
> experimentation to determine the import/export declarations in the
> bundle manifests. Although my bundles appear to be working I am not sure
> if they are completely declaring imports and exports.

Yes, trial and error is a lot of work.  Which is why I ended up using
the mangen "OSGi Bundle Manifest Generator."  I ran it once with R4
compliance and checked the resulting output into the base of the osgi
module.

http://oscar-osgi.sourceforge.net/m...osgiMangen.html

> BTW - Still waiting for the updated release of maven-osgi-plugin with
> Peter Kriens' manifest creation feature to ease or eliminate this
> problem. Do you know the status?

I'm sure you saw ... it just went in.

> By the time I had my osgi apacheds bundles working I noticed your J1
> efforts committed to the svn repository. (trunks/apacheds/osgi)
>
> I did a mvn install of the trunks/apacheds/osgi/server-main-osgi and
> tried running the apacheds.sh. Had some problems with this but I figured
> you may still be working to update/and test these. At this point I
> decided to take a look at your configuration admin impl.

Should be OK now.  We had both snapshot repo and SVN issues last week.

> Aren't the names for these objectclasses backwards? - Shouldn't the first 
one be called apacheFactoryConfiguration
> because it may include an apacheServiceFactoryPid (and a ManageServiceFact
ory) and the second one apacheServiceConfiguration
> because it doesn't use a apacheServiceFactoryPid (and thus like a  ManagedService)
?

No, they are not backwards.  Individual services need a reference to
their optional factory for the CM service to route them properly.  And
Factory's are services like a regular service.  We could collapse these
objectClass's, though.

> The other thing I noticed is that the ConfigurationAdminFactory.updateTarg
etServiceMatching method is
> checking for the attributes 'service.pid' and 'service.factoryPid' and not
 'apacheServicePid' or
> 'apacheServiceFactoryPid' and so does not recognize a valid configuration entry an
d just returns. Bug?

'apacheServicePid' and 'apacheServiceFactoryPid' are LDAP attributes and
thus should not "leak" into the CM service implementation.  They are
mapped to 'service.pid' and 'servicefactoryPid' in the store
implementation.  At Felix we could potentially have other store impl's
that don't care about attribute names we have chosen for a JNDI store
implementation.
 
> Have not any experience with ExtensibleObject until today. JXplorer does
> not seem to know what to do with this. Can it be used with visual
> editors to add arbitrary valid attributes?

This is a problem with extensibleObject and probably another reason to
not use it.

> Can ExtensibleObject be used to add invalid attributes? (Ones undefined
> in the schema? Like the ones in your ldif example below?)

We have to revisit this.  When this was written over a year ago there
was much less schema checking in ApacheDS.  Again, probably
extensibleObject will have to go.

... 
> Sounds okay. But I noticed JndiConfigurationStore has a
> "cm.entry.basedn" property for customizing it.

Sure, we'll continue to allow an override property.

Enrique

[ Post a follow-up to this message ]

On Thu, 2006-05-25 at 02:28 -0400, Enrique Rodriguez wrote:
> John E. Conlon wrote:
> ... 
>
> Yes, trial and error is a lot of work.  Which is why I ended up using
> the mangen "OSGi Bundle Manifest Generator."  I ran it once with R4
> compliance and checked the resulting output into the base of the osgi
> module.
>
> http://oscar-osgi.sourceforge.net/m...osgiMangen.html
> 
>
> I'm sure you saw ... it just went in.
Yes. Tried some experiments with it yesterday. In the process I broke my
homegrown ApacheDS bundles as it found undeclared imports. Which raises
some questions...

> 
>
> Should be OK now.  We had both snapshot repo and SVN issues last week.
Still having problems with this. Will start a new thread under another topic with the questi
ons.
> 
>
> No, they are not backwards.  Individual services need a reference to
> their optional factory for the CM service to route them properly.  And
> Factory's are services like a regular service.  We could collapse these
> objectClass's, though.
Ok. Now I understand.
> 
>
> 'apacheServicePid' and 'apacheServiceFactoryPid' are LDAP attributes and
> thus should not "leak" into the CM service implementation.  They are
> mapped to 'service.pid' and 'servicefactoryPid' in the store
> implementation.  At Felix we could potentially have other store impl's
> that don't care about attribute names we have chosen for a JNDI store
> implementation.
Yes, can see this mapping taking place in the EventDirContextListener.
> 
>
> This is a problem with extensibleObject and probably another reason to
> not use it.
> 
>
> We have to revisit this.  When this was written over a year ago there
> was much less schema checking in ApacheDS.  Again, probably
> extensibleObject will have to go.

Looks like all configuration entries will require their own schema
(objectclass and attributes) to be defined and tagged with (an Auxiliary
objectclass) of apacheFactoryConfiguration or
apacheServiceConfiguration.

Maybe this is not a bad thing. WDYT?

>
> ... 
>
> Sure, we'll continue to allow an override property.
>
> Enrique
>

[ Post a follow-up to this message ]