From dev-return-38022-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 11 17:14:46 2011 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 101A740D3 for ; Wed, 11 May 2011 17:14:46 +0000 (UTC) Received: (qmail 93484 invoked by uid 500); 11 May 2011 17:14:46 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 93339 invoked by uid 500); 11 May 2011 17:14:45 -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 93332 invoked by uid 99); 11 May 2011 17:14:45 -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 17:14:45 +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 pajbam@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 17:14:38 +0000 Received: by wyb33 with SMTP id 33so666442wyb.37 for ; Wed, 11 May 2011 10:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:mime-version:content-type:subject :date:in-reply-to:to:references:message-id:x-mailer; bh=IGjhm+0n+kmgCGXDVh1RncooFXFJUsuPrSrXJ+d0dVg=; b=uhdUl2c/3DhirUF2nomK9DWxWdyzXobD2up8gxv/gjKtUH1IfQHKVZQnZOYC+NUPvW b8divNE9Qy8LJAi8MDT5nEQQ8hf4HLbRnKO1c59ED1C4knobimXdtpetfzHtkIJJHaYT fFyVcJJqB2L7j+nzo4YSWU+9I9isqtDKMa4aI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=k7nh5DhyknKEhbGHMSy3kPOtyC2kdyhPojao1MNRFh0Jwd6HK4rwu8oCDWPxnNqSU9 XCx04CNg41wSHhwLUhrXl/29qLYN79hUxAswN95wvCrDPzKal4nYUVxinZYFKVK0qOl8 CzWCXgvCu3DEWZOqJNsFdVZQDwZLq4npeKQfQ= Received: by 10.227.172.206 with SMTP id m14mr448165wbz.29.1305134056554; Wed, 11 May 2011 10:14:16 -0700 (PDT) Received: from [192.168.0.52] (lon92-10-78-226-4-211.fbx.proxad.net [78.226.4.211]) by mx.google.com with ESMTPS id bs4sm233983wbb.18.2011.05.11.10.14.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 10:14:15 -0700 (PDT) Sender: Pierre-Arnaud Marcelot From: Pierre-Arnaud Marcelot Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-409339517 Subject: Re: [LDAP API] Codec extension mechanism direction (WAS: Re: OSGi startup and shutdown problems) Date: Wed, 11 May 2011 19:14:13 +0200 In-Reply-To: To: "Apache Directory Developers List" References: <4DCAB1C3.9060205@gmail.com> Message-Id: X-Mailer: Apple Mail (2.1084) --Apple-Mail-2-409339517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 mai 2011, at 18:46, Alex Karasulu wrote: > 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, >=20 > 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. >=20 > For the sake of speed I will define a direction and people can opine: >=20 > 1). Expose a means in the LDAP API (really SPI) to have codec = extensions > programmatically registered. I this already exists. >=20 > +1 >=20 > 2). Remove the standalone codec factory implementation that starts up = Felix. >=20 > Ok, that would be a relief. >=20 > 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. >=20 > 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. >=20 > This should serious remove some ugly and dangerous code we've got at = this > point in the LDAP API. > Absolutely. >=20 > 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 ? >=20 >=20 > 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. Yeah, the current implementation works fine in Equinox, without the = standalone mechanisms. Custom extensions are registered via bundle = activators. I'll keep an eye and help to maintain the complete OSGI compliance as we = go forward the refactoring. > That raises another related issue for ADS : what if an application is = already using an OSGi framework and wants to embed ADS ? I guess, the easiest thing would be to follow what we did in Studio: - Deploy the Shared/LDAP API bundles in the OSGI framework - Declare dependencies on Shared/LDAP API artifacts as provided in = pom.xml files - Access classes as usual=20 Regards, Pierre-Arnaud= --Apple-Mail-2-409339517 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 11 mai 2011, at 18:46, Alex Karasulu 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.

Yeah, the current implementation works fine in Equinox, without the standalone mechanisms. Custom extensions are registered via bundle activators.
I'll keep an eye and help to maintain the complete OSGI compliance as we go forward the refactoring.

That raises another related issue for ADS : what if an application is already using an OSGi framework and wants to embed ADS ?

I guess, the easiest thing would be to follow what we did in Studio:
- Deploy the Shared/LDAP API bundles in the OSGI framework
- Declare dependencies on Shared/LDAP API artifacts as provided in pom.xml files
- Access classes as usual 

Regards,
Pierre-Arnaud
--Apple-Mail-2-409339517--