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: Upgrading the OSGi
Date Fri, 21 Apr 2006 00:33:37 GMT
On Wed, 2006-04-19 at 15:41 -0500, John E. Conlon wrote:
> 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
> correction. 
> 
> Do we want to use Spring at all in this IntialContextFactory bundle?

Simplified the Backend Store by removing the Springframework and going
with an approach similar to what you did in the previous release.  

> 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(), 
>       factory, 
>       parameters );
> ...
> }
> //
> private InitialContextFactory getInitialContextFactory(String
> configuration)
>    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) {
>   e.printStackTrace();
>   fail(e.toString());
> }
> 
> It throws a:
> 
> 
> java.lang.NullPointerException
> 	at
> org.apache.directory.server.core.configuration.Configuration.toConfiguration(Configuration.java:58)
> 	at
> org.apache.directory.server.core.jndi.AbstractContextFactory.getInitialContext(AbstractContextFactory.java:83)
> 	at org.apache.ldap.server.ActivatorTest.testNullEnvironment
> (ActivatorTest.java:247)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 
> 
> 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.INITIAL_CONTEXT_FACTORY,
> 		"org.apache.ldap.server.jndi.CoreContextFactory");
> env.put(Context.PROVIDER_URL, "");
> 
> WDYT?
> 
> > 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.

Starting to work with the loader. 

Besides felix ui commands for loading ldif into the backend store, I
will add commands to dump or list the contents of the backend store.


John


Mime
View raw message