directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Tue, 13 Feb 2007 02:55:13 GMT
Alex Karasulu wrote:
> John E. Conlon wrote:
>> Hi Alex,
>> Thanks for the comments.  See inline for responses.
> Truly thanks for your effort to push OSGi along. I really want to go 
> this route but I want all our bases covered.
> Having read your response and Emmanuel's, I think I would like to wait 
> until we have a *non*-snapshot release of the OSGi plugin in the Maven 
> repository to use before tackling this in May or better yet June.  I 
> don't want the build to depend on SNAPSHOT plug-ins because I would 
> not allow a production release so long as we did.
> We can re-evaluate this and prep the team by then so we can all 
> participate in this OSGi aim together.  It would be nice to have you 
> involved with the guts of ApacheDS as well as being on the periphery 
> with the OSGi effort and likewise I'd like to see the rest of the team 
> more involved with the OSGi effort.  I'd like to also see if you can 
> get OSGi to give us certain things like JMX for free so we can better 
> control and instrument the server.
Although I have seen much activities on JMX done at Felix, I have not 
used any JMX with the server.  On the other hand we have a simple 
command line interface that we use for searching and one for loading 
ldif directly into the backend. (Without an LDAP server.)

> I want to know what our benefits are going to be and who is going to 
> be involved with making sure we get those benefits.  Also what's the 
> deal with Spring-OSGi? Is there some advantage to be gained there?  Do 
> we get the best of both worlds?
That's the goal of the Spring-OSGi - An IOC within the module (aka jar) 
that also manages registered service dependencies and service 
publications between the modules (bundles). 
Here is the home site:

In the sandbox work, the core server module utilizes a similar 
server.xml to the familiar one, but with a few new Spring-OSGi namespace 

The core server bundle's primary purpose is to offer to all other 
bundles an InitialContextServiceFactory service.  (A seperate bundle 
offers the LDAP service.)  It is still spring and pojo mostly though.  
Within the project for testing purposes OSGi can effectively be ignored, 
on just uses plan old JUnit or the Spring context extensions. As 
mentioned before 'in container testing' is done in an integration suite 
project that parallels the first. (Bundle/jars have to be built first to 
test them.)

Here is what our ApacheDS Spring-OSGi service publication looks like:

 <!-- Register the InitialContextFactoryImpl bean as an OSGi service -->
<osgi:service id="initialContextFactory" ref="initialContextFactoryService"
    interface="javax.naming.spi.InitialContextFactory"  />

<bean name="initialContextFactoryService"
        <constructor-arg ref="environment"/>
        <constructor-arg ref="configuration"/>

Benefit that is offered via OSGi is that it makes it easy to move in 
either a embedded server or a JNDi reference via properties to a remote 
one. (At run time without shutting down the JVM.)  Could have a 
combination of multiple servers running in the same VM or mixes of local 
and remote servers. 
> Let's get your documentation into the Apache confluence under the 1.5 
> confluence's developer guide area and more people on this team looking 
> at it and commenting on it.
Will do.
> This sound good?
No problems on resetting our priorities out to June.  


View raw message