Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 209.85.216.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ssb3YMXLRQNhQza34S/Jt4R6N5APpHPn+vwa/qlepWRyfN3OJ9J2QhHx0HoSeieeP6
         2gTwzMoR5J5L6HjPm7Ba0pZwzty8rmtyKx1gMHqlntAtVOkaBmTNGJ16cw5uZz5F6Q4U
         LfK0rQD6pGrVHzknKdbX8vRfZOaLT4dbhRUbw=
MIME-Version: 1.0
In-Reply-To: <BANLkTik5WZfJr=zpVcQm3ZhpkcpNPiRiNQ@mail.gmail.com>
References: <BANLkTimvDN_fYj5NBVuOdnk=HrVzpe0zcQ@mail.gmail.com>
	<4DCAB1C3.9060205@gmail.com>
	<BANLkTik5WZfJr=zpVcQm3ZhpkcpNPiRiNQ@mail.gmail.com>
Date: Wed, 11 May 2011 19:23:03 +0200
Message-ID: <BANLkTim5eBQf2yk1ooSKm=bRtQF=9g9NLg@mail.gmail.com>
Subject: Re: [LDAP API] Codec extension mechanism direction (WAS: Re: OSGi
 startup and shutdown problems)
From: Guillaume Nodet <gnodet@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

In Karaf, we have a simple provisioning mechanism called 'features'.
You can see an example at [1]
In its simpliest form, it's a list of urls pointing to OSGi bundles.
We usually use maven urls (which are real urls with a custom url
handler) so that we can download easily from configured maven
repositories.
We're working on automatic generation of such features from maven for
karaf 3.x, not sure when that'll be ready though (but we've lived with
hand-written ones for a while without problems).

Another way is to use OBR (OSGi Bundle Repository) and the maven
bundle plugin can easily generate obr xmls from an existing repo using
the bundle:index goal at [2]

Anyway, as long as Directory provide bundles, that should be enough.
If a user wants to install it in its own framework, he'll use a
provisioning mechanism of his choice.  Directory can help by providing
pre-built files as described above, but at the end, what's really
needed is a list of bundles to install.

[1] http://svn.apache.org/viewvc/karaf/branches/karaf-2.2.x/assemblies/features/standard/src/main/resources/features.xml?view=markup
[2] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-bundle%3Aindex

On Wed, May 11, 2011 at 18:46, Alex Karasulu <akarasulu@apache.org> wrote:
> On Wed, May 11, 2011 at 6:56 PM, Emmanuel Lecharny <elecharny@gmail.com>
> wrote:
>>
>> On 5/11/11 5:35 PM, Alex Karasulu wrote:
>>>
>>> Hi dev peeps,
>>>
>>> So after a long thread I just wanted to summarize the realizations and
>>> conclusions so we can set a clear direction for managing the codec
>>> extension
>>> mechanism. I created a separate clean thread for this here with
>>> Guillaume's
>>> core recommendation following.
>>>
>>> For the sake of speed I will define a direction and people can opine:
>>>
>>> 1). Expose a means in the LDAP API (really SPI) to have codec extensions
>>> programmatically registered. I this already exists.
>>
>> +1
>>>
>>> 2). Remove the standalone codec factory implementation that starts up
>>> Felix.
>>
>> Ok, that would be a relief.
>>>
>>> 3). Add a simple ClassLoader component to be used in standalone mode to
>>> load
>>> the plugin classes (from the plugin bundles defaulting to regular jars
>>> presumed to be on the classpath). Some configuration information drives
>>> how
>>> this component discovers what plugin classes to attempt to class load.
>>
>> Ok, fine.
>>>
>>> 4). Set it up so by default, the LDAP API uses the simple ClassLoader
>>> based
>>> discover/load/register mechanism. In an OSGi environment this is disabled
>>> to
>>> enable plugins to self register.
>>
>> Ok.
>>>
>>> This should serious remove some ugly and dangerous code we've got at this
>>> point in the LDAP API.
>>
>> Absolutely.
>>
>> Question : are we sure that teh API will continue to work in Studio, using
>> Equinox ? And are we sure we will be able to have felix started in ApacheDS
>> ?
>>
>
> Actually I think it is using equinox at the present moment. If I remember
> correctly we're not using the standalone mechanism when in the eclipse
> environment. PAM I think found a way to get the bundle loaded under eclipse
> OSGi (a.k.a. equinox). Might want to get confirmation from PAM though.
>
>>
>> That raises another related issue for ADS : what if an application is
>> already using an OSGi framework and wants to embed ADS ?
>
> That's not a problem since basically they can load just the bundles. We can
> carry ApacheDS with installers inside Karaf with our standalone
> distribution. Those loading ADS into an existing environment need only issue
> a load from the bundle repository. I think there's some magic there making
> your local maven repository into an OSGi bundle repository. I wonder if
> Karaf knows how to pull bundles down too from remote repositories, I bet
> Guillaume can answer that :).
> Regards,
> Alex


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

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/