directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: Configuration objectclass
Date Thu, 25 May 2006 19:19:52 GMT
On Thu, 2006-05-25 at 02:28 -0400, Enrique Rodriguez wrote: 
> 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.
> > 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.
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...  

> > 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.
Still having problems with this. Will start a new thread under another topic with the questions.
> > 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)?

> 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. 
> > 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 
> implementation.
Yes, can see this mapping taking place in the EventDirContextListener. 
> >> 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.

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

Maybe this is not a bad thing. WDYT? 

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

View raw message