directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] Any interest in using Apache Karaf for Apache DS ?
Date Wed, 09 Jun 2010 05:51:17 GMT
On Tue, Jun 8, 2010 at 18:07, Emmanuel Lecharny <elecharny@gmail.com> wrote:

> On 6/8/10 2:51 PM, Guillaume Nodet wrote:
>
>> I don't have much knowledge of DS really, but in order to make things run
>> smoothly in OSGi, the first step is obviously to turn those into OSGi
>> bundles.
>> Karaf comes later if you want to use it as your runtime container instead
>> of
>> using your own org.apache.directory.server.UberjarMain + everything that
>> Karaf provide.
>>
>> Turning ApacheDS jars into OSGi bundles should be relatively
>> straightforward
>> if there is no shared packages, which means each jar contain a set of
>> packages, but those are different (you can't find classes in the same
>> package in different jars).  This would be the main problem (though there
>> are some ways to still do that in OSGi).
>> A first step should be easy and mostly consist in:
>>   * defining a set of properties in the parent pom (such as the
>> camel.osgi.*
>> in https://svn.apache.org/repos/asf/camel/trunk/parent/pom.xml)
>>   * change the packaging of all jars to bundle, and define the properties
>> that need to be overriden (usually the exported packages as in
>> http://svn.apache.org/repos/asf/camel/trunk/components/camel-csv/pom.xml)
>> It should be easy but will certainly need to be refined over the time.
>>
>> A second step is to provide a good osgi integration, mostly if / when you
>> have some discovery mechanisms such as pluggable parts.  Those are usually
>> done using some kind of META-INF/services in a plain java world, but this
>> is
>> not always the best way to go in OSGi.  I don't know if / where that
>> applies
>> to ApacheDS.  This can be deferred, as a simple OSGi integration can be
>> made
>> to work without rewriting those bits for OSGi.
>>
>> The last step is to actually use OSGi as your default container, which
>> would
>> actually help finding problems in OSGi, but this it could be quite a
>> disruptive move for the users, because a lot of the configuration would
>> have
>> to change.  This is where Karaf actually comes into play and provides you
>> a
>> ready to use container.
>>
>>
> Ok, all this won't be obvious... We have to think about the consequences on
> our code base. And as we are targetting a 2.0-RC1 release pretty soon, I
> suggest we wait a bit before moving to OSGi so that the code base stabilize.
> Then we can spend some time to OSGIfy the code, *before* going to 2.0-RC1.
>
>  Actually, i've just seen that trunk includes an osgi module that seems to
>> build a big bundle containing lot (most ?) of the ApacheDS classes.  That
>> is
>> also one way of providing an OSGi integration point.  Might not be the
>> best,
>> but it allows users to actually deploy DS in an OSGi environment, although
>> not in a very modular way.
>>
>>
> It was an early effort, not sure we want to resume it?


I guess no if we plan to go down a better way.  Stefan say that there are
some split packages.
I think this issue need to be addressed asap.


>
>  So there are different ways to go, I guess the one you want to take need
>> to
>> be discussed.
>>
>>
> Yop. One thing : I will go in Normandy end of next week (week-end at
> Langrune s/mer), may be a good opportunity to discuss some technical aspect
> or even to give it a try F2F on a branch on friday (I can be there on friday
> morning instead of evening). Your call.


Sure, that's a good idea.  We can arrange that off-list.


>
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.nextury.com
>
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message