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:
http://www.springframework.org/osgi
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.)
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="org.apache.directory.osgi.backend.InitialContextFactoryImpl"
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.
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.
John
