directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Configuration objectclass
Date Tue, 23 May 2006 23:34:50 GMT
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 one be called apacheFactoryConfiguration
because it may include an apacheServiceFactoryPid (and a ManageServiceFactory) and the second
one apacheServiceConfiguration
because it doesn't use a apacheServiceFactoryPid (and thus like a  ManagedService)? 

The other thing I noticed is that the ConfigurationAdminFactory.updateTargetServiceMatching
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 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



Mime
View raw message