Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D2A80496C for ; Wed, 11 May 2011 16:46:50 +0000 (UTC) Received: (qmail 48849 invoked by uid 500); 11 May 2011 16:46:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 48806 invoked by uid 500); 11 May 2011 16:46:50 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 48799 invoked by uid 99); 11 May 2011 16:46:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 May 2011 16:46:50 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-wy0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 May 2011 16:46:44 +0000 Received: by wyb33 with SMTP id 33so639607wyb.37 for ; Wed, 11 May 2011 09:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=I+RCb2d9QEFhXdkBc82JBpRW8EvgNNzN3ktYFbtD8AA=; b=M/5WywkQa9Xml8a8CchIAU2yvjb0Q+kirBWhGGFGj0t/dqK9gu2XdvO4nFqYkqiLhj 2WQa4yLFi5y7q3HtjTpk2xpKIvqhwTjg788/P1aQ2qNk91473myC/FbOfn5u2W98Mmk3 AovriZ4On5r0eOs6Yt/bQdAky52m2+cAvCrpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=uyc2vcQ4y5PG8tJtcPwUVQqexrpGMJlcZcs9TS5MUdIIHS1bzbld1Gbx5ESMZBVNhV E0zhH2h680pWN1BSFpbGb9ve8iDWPXuQe2wNuOBEZLBqlIfIfVCfqyptmOjonzUgO5MV z2RYlQUaEu4jHTxp153Iki8uG9tnc8pqnNTxo= MIME-Version: 1.0 Received: by 10.216.65.203 with SMTP id f53mr759736wed.54.1305132382956; Wed, 11 May 2011 09:46:22 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.216.237.142 with HTTP; Wed, 11 May 2011 09:46:22 -0700 (PDT) In-Reply-To: <4DCAB1C3.9060205@gmail.com> References: <4DCAB1C3.9060205@gmail.com> Date: Wed, 11 May 2011 19:46:22 +0300 X-Google-Sender-Auth: BybeHfP6WflHgChw1_tzYzWwCsw Message-ID: Subject: Re: [LDAP API] Codec extension mechanism direction (WAS: Re: OSGi startup and shutdown problems) From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=000e0ce0b4ea122e4204a302d0ee --000e0ce0b4ea122e4204a302d0ee Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 6:56 PM, Emmanuel Lecharny 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 --000e0ce0b4ea122e4204a302d0ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2011 at 6:56 PM, Emmanuel Lechar= ny <elecharny@g= mail.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 extensio= n
mechanism. I created a separate clean thread for this here with Guillaume&#= 39;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 loa= d
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 t= o
enable plugins to self register.
Ok.

This should serious remove some ugly and dangerous code we've got at th= is
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 a= t the present moment. If I remember correctly we're not using the stand= alone 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 g= et confirmation from PAM though.
=A0
That raises another related issue for ADS : what if an application is alrea= dy using an OSGi framework and wants to embed ADS ?
That's not a problem since basically they can load just th= e bundles. We can carry ApacheDS with installers inside Karaf with our stan= dalone distribution. Those loading ADS into an existing environment need on= ly 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=A0
--000e0ce0b4ea122e4204a302d0ee--