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:
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.)
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="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.
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
