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 08:05:04 GMT
Alex Karasulu wrote:
> 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?
No its we, Apache DS.
There is a sandbox project called apache-core-felix-tui that offers a 
felix text user interface for simple searching and loading ldif into a 
jndi backend.

Another thought - more radical though (its late) is to run our bundles 
in the same OSGi environment (Felix or Eclipse) with LDAPStudio.  LDAP 
Studio is after all an Eclipse RCP - "Composed of several Eclipse (OSGi) 
plugins, LDAP Studio can be easily upgraded with additional plugins. " 

>>> 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?
Not all the bundles but some.   LoggingService and Mina have 
integrations tests in place.  Note Logging Service will most likely be 
going away as I have worked with the Ceki to replace it with an OSGi 
supported Slf4j (on current slf4j trunk which is at 1.3.0-SNAPSHOT).  
Full very nice integration test suite is in place over at the slf4j that 
is based on Swing-OSGi. 

Also please note that Spring-OSGi API is very much in a state of flux 
although the testing APIs seems to be pretty stable.

The big mama test to do is the integration test suite for the 
configuration admin service implementation that I committed a few weeks 
ago to the sandbox.  The configuration admin service sits on top of a 
DAOConfigurationStore interface which in our case is a 
JndiConfigurationStore implementation.  The JndiConfigurationStore 
depends on the InitialContextFactory service I described below.  
Configuration Admin configurations are persisted in our backend and 
these can be created and manipulated via Ldap or the Configuration Admin 
APIs.   The ConfingAdmin already has a pretty complete set of Unit tests 
and Spring integration tests internal to the project but to test this 
via the Spring-OSGi OSGi integration test, I will need all the bundles 
we (apacheDS)  have created to date. Sort of a super integration test.

(PS - My company is using the earlier version of the Configuration Admin 
and all the ApacheDS bundles to configure it's secret stuff. ;-) )
>> 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.
> Alex

View raw message