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 6DC83477B for ; Wed, 11 May 2011 15:35:49 +0000 (UTC) Received: (qmail 8141 invoked by uid 500); 11 May 2011 15:35:49 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 8090 invoked by uid 500); 11 May 2011 15:35:49 -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 8083 invoked by uid 99); 11 May 2011 15:35:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 May 2011 15:35:49 +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 (nike.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 15:35:41 +0000 Received: by wyb33 with SMTP id 33so569781wyb.37 for ; Wed, 11 May 2011 08:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=WY86AMib61HBM0B986vNwWE+et2eLfInrEXgpCgZ++U=; b=ZNOWKxHarcTospH+0wHXLQZclzdMkU5I/fJW3ynt24PC0LRfZYnlI4vYPFLPPp66DF yI1QRL5B6HOfLxWUZLscNKRaBmn6F7cozPSjKuunb6fAl5QhHcbtzYyqUSRlIoZjIAvC mqGY77AVtNVhy3q/ppecI6xHxD/NMVTSlcPf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=xu7G8E7/B/CbjUGhd+p8Jfl1gwBAEcGu8JuWibSms4bGmRd6+u+yw50CgiN3JC5UPY o19DuTt95ilJgHB38dV64N1q2ptBa6cw00TBHhS/iPul2oCYUCIb7lJW91uQ8LTamTPb mO1uyGqJ7Ne2bUdISb6J67xi0ZGQC8xjycbP4= MIME-Version: 1.0 Received: by 10.216.65.203 with SMTP id f53mr684671wed.54.1305128120987; Wed, 11 May 2011 08:35:20 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.216.237.142 with HTTP; Wed, 11 May 2011 08:35:20 -0700 (PDT) Date: Wed, 11 May 2011 18:35:20 +0300 X-Google-Sender-Auth: s9Onq9PQvFBiwFyfb__deA8WuQ8 Message-ID: Subject: [LDAP API] Codec extension mechanism direction (WAS: Re: OSGi startup and shutdown problems) From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=000e0ce0b4ea09b17804a301d27c X-Virus-Checked: Checked by ClamAV on apache.org --000e0ce0b4ea09b17804a301d27c Content-Type: text/plain; charset=ISO-8859-1 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. 2). Remove the standalone codec factory implementation that starts up Felix. 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. 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. This should serious remove some ugly and dangerous code we've got at this point in the LDAP API. Thoughts? Thanks, Alex On Wed, May 11, 2011 at 6:14 PM, Alex Karasulu wrote: > > > On Wed, May 11, 2011 at 6:03 PM, Guillaume Nodet wrote: > >> What we've done for Camel for example is to allow those libraries to >> leverage OSGi if deployed in OSGi and default to a basic mode in other >> cases. >> >> For Camel, components can be create by users (though I guess it's the >> same here, not average users). Camel can discover components using a >> pluggable discovery mechanism. When deployed in OSGi, Camel >> automatically select an OSGi aware discovery mechanism that will be >> able to look into existing bundles for such components (well, it's in >> reality slightly more complicacted, but thats the idea). When in a >> non OSGi environement, the default discovery mechanism just scans for >> META-INF/services/xxx which define camel components. >> >> The idea here is that if the user wants to use OSGi, he'll be able to >> use the OSGi modularity layer and dynamism to deploy things at runtime >> and all the OSGi goodness. Else, we just use a very simple and basic >> things that works very nicely in a flat classloader. >> >> > That sounds very reasonable to me. This is the best path. Thanks Guillaume > for helping us see this clearly. > --000e0ce0b4ea09b17804a301d27c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi dev peeps,

So after a long thread I just wanted to=A0summari= ze the realizations and conclusions so we can set a clear direction for man= aging the codec extension mechanism. I created a separate clean thread for = this here with Guillaume's core recommendation following.=A0

For the sake of speed I will define a direction and peo= ple can opine:

1). Expose a means in the LDAP API = (really SPI) to have codec extensions programmatically registered. I this a= lready exists.

2). Remove the standalone codec factory implementation = that starts up Felix.

3). Add a simple ClassLoader= component to be used in standalone mode to load the plugin classes (from t= he plugin bundles defaulting to regular jars presumed to be on the classpat= h). Some configuration information drives how this component discovers what= plugin classes to attempt to class load.

4). Set it up so by default, the LDAP API uses the simp= le ClassLoader based discover/load/register mechanism. In an OSGi environme= nt this is disabled to enable plugins to self register.=A0

This should serious remove some ugly and dangerous code we'v= e got at this point in the LDAP API.

Thoughts?

Thanks,
Alex

On Wed, May 11, 2011 at 6:14 PM, Alex Karasulu <akarasulu@apache.org> wrote= :


On Wed, May 11, 2011 a= t 6:03 PM, Guillaume Nodet <gnodet@gmail.com> wrote:
What we've done for =A0Camel for example is to allow those libraries to=
leverage OSGi if deployed in OSGi and default to a basic mode in other
cases.

For Camel, components can be create by users (though I guess it's the same here, not average users). =A0Camel can discover components using a
pluggable discovery mechanism. =A0When deployed in OSGi, Camel
automatically select an OSGi aware discovery mechanism that will be
able to look into existing bundles for such components (well, it's in reality slightly more complicacted, but thats the idea). =A0 When in a
non OSGi environement, the default discovery mechanism just scans for
META-INF/services/xxx which define camel components.

The idea here is that if the user wants to use OSGi, he'll be able to use the OSGi modularity layer and dynamism to deploy things at runtime
and all the OSGi goodness. =A0 Else, we just use a very simple and basic things that works very nicely in a flat classloader.


That sounds very reasonable to me. This is the best path. Thanks Guillaume= for helping us see this clearly.
--000e0ce0b4ea09b17804a301d27c--