directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: Configuration objectclass
Date Thu, 25 May 2006 06:28:36 GMT
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 

> 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 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
> 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)? 

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.updateTargetServiceMatching
method is 
> checking for the attributes '' and 'service.factoryPid' and not 'apacheServicePid'
> 'apacheServiceFactoryPid' and so does not recognize a valid configuration entry and just
returns. Bug?

'apacheServicePid' and 'apacheServiceFactoryPid' are LDAP attributes and 
thus should not "leak" into the CM service implementation.  They are 
mapped to '' 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 

>> 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?

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.

>> 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.

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


View raw message