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 24ADD472B for ; Wed, 11 May 2011 14:55:48 +0000 (UTC) Received: (qmail 10030 invoked by uid 500); 11 May 2011 14:55:48 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 9989 invoked by uid 500); 11 May 2011 14:55:48 -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 9982 invoked by uid 99); 11 May 2011 14:55:47 -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 14:55:47 +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.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 May 2011 14:55:39 +0000 Received: by wwa36 with SMTP id 36so700869wwa.1 for ; Wed, 11 May 2011 07:55:19 -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=bZmQ8/CLoRkinOGZ7mcARQbb0IaKeD07DI+16QHzrt4=; b=wgslfZWb1yD5W/wFBezkjT0efkPWQ0fOn1hFRoS0BS2i0e2lEvs/D8NR1p8b/2lwG8 HY2lxwG1U9A2sJ9gYtsR4l7dA+hRMTurfkxdVkOSV38h8kd2zkElUxmBiYCTEo6FSLFH S1STdyTy81nYXAOLYenvIq9DlmBj1IF/dWpCY= 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=IWY2WML4mXXbRTxpiDmuRbgKlc1IGhi+dtHQiQp8q5RuFg1Ur74jKv7xm0q5a9G5F9 knfqfZBDU33wLAu2ibYT9lmLOlx1v7KoF3qUELVdW4seY7/jaXtHfKfaDFtfnum7KoIk OL2MylB4oExQlEjTmkyjGPmRd77HqKm9OQsnA= MIME-Version: 1.0 Received: by 10.216.255.206 with SMTP id j56mr645801wes.39.1305125710165; Wed, 11 May 2011 07:55:10 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.216.237.142 with HTTP; Wed, 11 May 2011 07:55:10 -0700 (PDT) In-Reply-To: References: <4DC92820.2010602@gmail.com> <4DCA54A7.1030804@gmail.com> Date: Wed, 11 May 2011 17:55:10 +0300 X-Google-Sender-Auth: duV31UDNHVDTD_3-4BNlfQ7Jiec Message-ID: Subject: Re: OSGi startup and shutdown problems From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=20cf301e31c357760204a30142f7 X-Virus-Checked: Checked by ClamAV on apache.org --20cf301e31c357760204a30142f7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 5:14 PM, Guillaume Nodet wrote: > On Wed, May 11, 2011 at 15:42, Alex Karasulu wrote: > > Thanks Guillaume for your thoughts. Responding in this post to both of > you > > in line ... > > > > On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny > > > wrote: > >> > >> On 5/11/11 10:47 AM, Guillaume Nodet wrote: > >>> > SNIP ... > > By "hide the OSGi stuff", do you mean embed the OSGi container in the > > application? > > Looking at the current api, an average user that does not use OSGi > won't see the fact that an embedded Felix is launched and it has no > access to it anyway, so that's what I mean by hidden. > > The goal was not to grant programatic access to the OSGi container. The goal was to just expose a directory where the user can drop bundles and on startup they would be used to extend the codec. SNIP .. >>> > >>> that you export the slf4j pacakge in version 1.6.0 from the system > >>> bundle. What if a user start using a [1.6.1,2) range when importing > >>> that package ? > > > > Do you mean to say the user, writes and added a new bundle for an > extension, > > and the extension bundle depends on slf4j 1.6.1 for example? > > Yes > > Agreed if a bundle supplying the 1.6.1 SLF4J API is not provided we'll get an exception from the container. However if the 1.6.1 API is provided in the bundle loading directory it should work just fine. However this is not that realistic of a situation because users that are going to use the LDAP API in this standalone scenario to extend it will have to use a specific version of the LDAP API and develop their extensions/plugins according those dependencies. Let's step through the process: 1). The user of the API wants to extend the codec in the LDAP API to handle the encoding and decoding of Foo extended operations present specifically in Bar LDAP server. 2). User creates a Maven project to create the Foo extended operation codec plugin including the dependency for the LDAP API version they're working with. Naturally they would use the SLF4J API dependency that the LDAP API version uses. In this case the aforementioned scenario does not result. The plugin for the Foo codec extension bundle would naturally have to follow the dependencies used by the LDAP API. > > Again do you [Guillaume] mean embedding a OSGi container when you say > > hiding? > > Yes, embedding but not giving the user access to it. > > OK I see, we do not intend to give the user access to the container. Is there some reason why you think we should grant user access to the container? > Other possible problems are that OSGi does not work in some > environments like Google App Engine for example, because it needs > access to the file system. > > Good point. This might be a good reason to just avoid using OSGi here. > I'm quite sure I haven't fully grasped what the use case is (i.e. when > / how / who will people develop and use those bundles / extensions), > but a simple URLClassLoader would look like a way easier solution to > me when not in OSGi. If that cause problem, you could always say: > well, OSGi solves those problems so you should use it and the code is > able to leverage it. > > This decision is really about a tradeoff. The codec needs the ability to allow users to extend it to handle new extended req/resp pairs and controls. The server and studio exist in OSGi environments where there's no problem with using OSGi bundles for the modularity mechanism. Plus when used in these two scenarios, the LDAP API extensions can be dynamically loaded, unloaded and/or have new versions loaded, and this is a capability is appealing. The tradeoff problem appears when the LDAP API is used standalone outside of these environments in a client application or with some command line tool for ldap clients. So having OSGi bundles for codec extensions, how do we re-use those extensions in the standalone scenario? The simple class loading mechanism should work just fine with the plugin bundles defaulting to regular jars, and this is how the standalone version of the codec factory can work while the OSGi version can be used in the ApacheDS and Studio use cases. I'm starting to think the classloader based mechanism might be best for standalone usage. I guess I'm just missing the use cases to understand that this could > be a good solution, as I don't even see where the bundles loaded are > used at all > > The plugin bundles do not contain any services. The activators of the plugin bundles simply register classes in the plugin bundle with the main service exported by the host application: the codec factory service. Looking at this big fat mess a good rule of thumb is starting to emerge: Do not embed OSGi containers in APIs, because you cannot be sure of the environments in which that API will be used. The best way to proceed would be to expose a means to programmatically register new extension components with the API, and leave the mechanism to load and register the plugin components outside the API to be handled by some other component. Thoughts? Regards, Alex --20cf301e31c357760204a30142f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2011 at 5:14 PM, Guillaume Nodet= <gnodet@gmail.com= > wrote:
On Wed, May 11, 2011 at 15:42, Alex Karasulu <akarasulu@apache.org> wrote:
> Thanks Guillaume for your thoughts. Responding in this post to both of= you
> in line ...
>
> On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny <elecharny@gmail.com>
> wrote:
>>
>> On 5/11/11 10:47 AM, Guillaume Nodet wrote:
>>>
SNIP ...
=A0
> By "hide the OSGi stuf= f", do you mean embed the OSGi container in the
> application?

Looking at the current api, an average user that does not use OSGi won't see the fact that an embedded Felix is launched and it has no
access to it anyway, so that's what I mean by hidden.


The goal was n= ot to grant programatic access to the OSGi container. The goal was to just = expose a directory where the user can drop bundles and on startup they woul= d be used to extend the codec.
=A0
SNIP ..

>>>
>>> that you export the slf4j pacakge in version 1.6.0 from the sy= stem
>>> bundle. =A0 What if a user start using a [1.6.1,2) range when = importing
>>> that package ?
>
> Do you mean to say the user, writes and added a new bundle for an exte= nsion,
> and the extension bundle depends on slf4j 1.6.1 for example?

Yes


Agreed if a bu= ndle supplying the 1.6.1 SLF4J API is not provided we'll get an excepti= on from the container. However if the 1.6.1 API is provided in the bundle l= oading directory it should work just fine.

However this is not that realistic of a situation becau= se users that are going to use the LDAP API in this standalone scenario to = extend it will have to use a specific version of the LDAP API and develop t= heir extensions/plugins according those dependencies. Let's step throug= h the process:

1). The user of the API wants to extend the codec in th= e LDAP API to handle the encoding and decoding of Foo extended operations p= resent specifically in Bar LDAP server.

2). User c= reates a Maven project to create the Foo extended operation codec plugin in= cluding the dependency for the LDAP API version they're working with. N= aturally they would use the SLF4J API dependency that the LDAP API version = uses.

In this case the aforementioned scenario does not resul= t. The plugin for the Foo codec extension bundle would naturally have to fo= llow the dependencies used by the LDAP API.
=A0
> Again do you [Guillaume] mean embedding a OSGi conta= iner when you say
> hiding?

Yes, embedding but not giving the user access to it.


OK I see, we do not intend to give the= user access to the container. Is there some reason why you think we should= grant user access to the container?
=A0
Other possible problems are that OSGi does not work in some
environments like Google App Engine for example, because it needs
access to the file system.


Good point. This might be a good reaso= n to just avoid using OSGi here.
=A0
I'm quite sure I haven't fully grasped what the use case is (i.e. w= hen
/ how / who will people develop and use those bundles / extensions),
but a simple URLClassLoader would look like a way easier solution to
me when not in OSGi. =A0 If that cause problem, you could always say:
well, OSGi solves those problems so you should use it and the code is
able to leverage it.


This decision is really about a tradeo= ff. The codec needs the ability to allow users to extend it to handle new e= xtended req/resp pairs and controls. The server and studio exist in OSGi en= vironments where there's no problem with using OSGi bundles for the mod= ularity mechanism. Plus when used in these two scenarios, the LDAP API exte= nsions can be dynamically loaded, unloaded and/or have new versions loaded,= and this is a capability is appealing.

The tradeoff problem appears when the LDAP API is used = standalone outside of these environments in a client application or with so= me command line tool for ldap clients. So having OSGi bundles for codec ext= ensions, how do we re-use those extensions in the standalone scenario?

The simple class loading mechanism should work just fin= e with the plugin bundles defaulting to regular jars, and this is how the s= tandalone version of the codec factory can work while the OSGi version can = be used in the ApacheDS and Studio use cases.

I'm starting to think the classloader based m= echanism might be best for standalone usage.=A0

I guess I'm just missing the use cases to understand that this could be a good solution, as I don't even see where the bundles loaded are used at all


The plugin bun= dles do not contain any services. The activators of the plugin bundles simp= ly register classes in the plugin bundle with the main service exported by = the host application: the codec factory service.

Looking at this big fat mess a good rule of thumb is st= arting to emerge:

Do not embed OSGi containers in = APIs, because you cannot be sure of the environments in which that API will= be used.

The best way to proceed would be to expose a means to= =A0programmatically=A0register new extension components with the API, and l= eave the mechanism to load and register the plugin components outside the A= PI to be handled by some other component.

Thoughts?

Regards,
A= lex
--20cf301e31c357760204a30142f7--