directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 11:38:25 GMT
On 10/20/11 1:19 PM, Göktürk Gezer wrote:
> Hi All,
> I see lots of discussions took place. So i would like to say some more.
> On Thu, Oct 20, 2011 at 1:58 PM, Emmanuel Lécharny<>wrote:
>> On 10/20/11 12:33 PM, Alex Karasulu wrote:
>>> On Thu, Oct 20, 2011 at 1:18 PM, Emmanuel Lecharny<>**
>>> wrote:
>>>   On 10/20/11 12:06 PM, Alex Karasulu wrote:
>>>>   On Thu, Oct 20, 2011 at 12:43 PM, Guillaume Nodet<>
>>>>>   wrote:
>>>>>   I think you first need to define your constraints and what you want
>>>>>> focus on.
>>>>>>   Excellent point so let's recap a little. In the API we have certain
>>>>> functionality extension points:
>>>>> 1). Codec Extensions
>>>>> These extension points are for adding support LDAP extended operation
>>>>> and
>>>>> LDAP control support so the API can handle them explicitly as structured
>>>>> elements rather than opaque unstructured data. This is pretty well
>>>>> defined
>>>>> and understood by the Directory Team I think and we opted for using a
>>>>> non-OSGi based ClassLoader mechanism. If this has changed please correct
>>>>> me.
>>>>>    Those codec are not supposed to be written by external users.
>>> I disagree with the this statement above. If codec extensions are not to
>>> be
>>> written by non-API committers then why are we going to all this trouble
>>> class loading them and making them pluggable?
>> That's a good question. The problem is that in some case, and mostly on the
>> API, one codec for an extended operation *might* have different
>> implementations depending on the targeted software (and we probably can
>> thank M$ for such a mess).
>>> Our users might want to implement a control using our API for an LDAP
>>> server
>>> which exposes controls or extended operations which we have not supported.
>>> This provides a means for them to extend our API and achieve their goals.
>> Well, assuming that writing a codec is not frankly easy, I'd rather have a
>> request and write it myself...
>>>   Another part of the problem is making this work in both a non-OSGi client
>>>>> side API environment in addition to an OSGi based environment in both
>>>>> ApacheDS and Studio.
>>>>> Is this correct?
>>>>>   Aye aye, sir !
>>>>   Since when was I knighted by the Queen :-D.
>> Well, I was more thinking about Full Metal Jacket, here :)
>>>   Also we had some conversations in the past of not actually using OSGi to
>>>>> load schema into the API. Sorry I don't have a email reference to the
>>>>> past
>>>>> thread. Did our position change on this topic in the recent past?
>>>>>   Nope, this is exactly the problem we have : be able to class-load those
>>>> schema extensions the ol' Java way (ie, class.forName() )
>>>>   Sorry to beat a dead horse here but OK so we are not trying to use OSGi
>>> for
>>> loading schema in all environments: client API, apacheds, and studio?
>> If we can have a solution that cover the three cases, I buy it. If we have
>> to class load the Java way schema element because the API will be used
>> outside of an OSGi container, then be it.
> It didn't take much attention as i see, but we handled that topic yesterday
> :) I think preserving the shared api ıs a must. And if we want to provide a
> mechanism that can work on both OSGI and nonOSGI environment, fragments is
> not an option, it is a must too. But everybody is missing something here. By
> using fragments, we're not adding any new extension point other than it
> already provided. It is just a way to polish our looking in OSGI
> environment.for nonOSGI environment everything will be just same,hard.
> So the aim of the code i currently patched is to show we can seperate OSGI
> and nonOSGI environments.
> When launched inside an OSGI, that code creates the necessary listeners for
> new Comparator addition, in OSGI way using Service registrations. And use
> them internally.
> When it is launched outsıde the OSGI, it does not change anything and
> somebody can provide their extension as fragment or plain jar at all.
> So while providing fragment extensions out of the box, we also create an
> extra OSGI extension point right now(for Comparators) So we provide 2 main
> way. Its developer's choice to choose which one.

Ok, get it now. Thanks for the clarification.

> I must suggest some other idea that will change the way we think. We can
> embed OSGI inside shared. By embedding i really mean embedding. So our
> shared api launchs its own OSGI framework and its own extension points. so
> whether it is launched in or out of OSGI environment, it will have its own
> execution context. And we provide that context just for extensions. It might
> work like that too. But if you ask me, i say it is not necessary.

We did that months a go, intergrating Felix in the API. We decided it 
was not a good idea (don't remember extacly why). In any case, we 
removed felix from the API.Göktürk

Emmanuel Lécharny

View raw message