directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Tue, 13 Feb 2007 05:10:07 GMT
John E. Conlon wrote:
> 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.)

Can you elaborate on the we?  Is this your company?

>> 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 
> enhancements.
> 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.)

Do you already have these tests based on Spring-OSGi in place already to 
test out the behavior of the bundles?

> 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"
> class=""
>          destroy-method="destroy"
>          init-method="init">
>        <constructor-arg ref="environment"/>
>        <constructor-arg ref="configuration"/>
> </bean>
> 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.

Yeah that's cool.  I like that.

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

Thanks for understanding.


View raw message