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/mangen/OpenosgiMangen.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 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 'service.pid' and 'service.factoryPid' and not 'apacheServicePid' or
'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 '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.
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.
Enrique
