directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: Upgrading the OSGi
Date Wed, 19 Apr 2006 20:41:04 GMT
On Tue, 2006-04-18 at 17:34 -0400, Enrique Rodriguez wrote:
> John E. Conlon wrote:
> ...
> > Have updated it by encapsulating it within a M2 OSGi plugin and have
> > replaced the hard coding of the directory configuration with a
> > springframework based server.xml file.
> OK, makes sense.  You may have noticed I'm working to upgrade this stuff 
> to M2 at the moment, too, so it is subject to change. 
Yes I see the updates.

>  Unfortunately, a 
> lot has changed, in particular the MINA interfaces and everything moving 
> from Oscar to Felix and Maven to M2, so there is a bit of work.
> > The issue I am having problems with is the loading of ldif using the
> > ldifDirectory property in the server.xml file.  
> > 
> > <property name="ldifDirectory">
> >       <value>src/test/resources/nonspecific.ldif</value>
> > </property>
> We could use some code samples, more server.xml, or even logging output 
> to try to help diagnose this.
I will send you the bundle for review (out of band) after I clean it up some.

> ...
> > Being a newbee on embedding the server any ideas or hints on how to
> > approach the problem would be very appreciated.
> The way I would approach this is to get the "loader" OSGi bundle 
> working.  
> You are combining starting the store as a service, adding 
> entries to it, and a bunch of Spring stuff not meant for OSGi-land, 
> which, IMO, should be separate.  
Agree.  Have up to now only worked with the directory as a service  so
was not approaching it with an OSGi backplane mindset.  Thanks for the

Do we want to use Spring at all in this IntialContextFactory bundle?

Another question I have is related to how the underlying
InitialContextFactory implementation CoreContextFactory handles a null
Hashtable object. Here is how I create the implementation that will be
registered as a service.:

factory = getInitialContextFactory(configuration);
Dictionary parameters = new Hashtable();
registration = bundleContext.registerService
    ( InitialContextFactory.class.getName(), 
      parameters );
private InitialContextFactory getInitialContextFactory(String
   throws NamingException {
  Hashtable env = new Hashtable( getStartEnvironment(configuration) );
  CoreContextFactory coreContextFactory = new CoreContextFactory();
  coreContextFactory.getInitialContext( env );
  return coreContextFactory;

While testing if I do a 

try {
  context = factory.getInitialContext(null);
} catch (Exception e) {

It throws a:

	at org.apache.ldap.server.ActivatorTest.testNullEnvironment
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke
	at sun.reflect.DelegatingMethodAccessorImpl.invoke
	at java.lang.reflect.Method.invoke(
	at junit.framework.TestCase.runTest(

According to the javax.naming.spi.InitialContextFactory interface
javadoc an implementation should be able to take a null env parameter. 

I think an OSGi InitialContextFactory Service should return a valid
(default) Context if a null env is given. What if I wrapped
CoreContextFactory and replaced nulls with an env using a simple
Configuration like:

env.put(Context.PROVIDER_URL, "");


> To this end I created the LdifLoader as 
> an Oscar console Command.  Once the JNDI provider bundle is started then 
> the LdifLoader command can use the registered JNDI interface from the 
> OSGi backplane.  This needs an update to Felix.  Then, at the Felix 
> console you can call:
> ->  load <path/to/file> <context>
> For example:
> ->  load /home/user/my.ldif dc=example,dc=com
> One benefit here is that you can use 'load' more than just once at startup.

Yes I looked at the Loader bundle. I can work on that one next.


View raw message