directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 17:22:12 GMT
On Thu, Oct 20, 2011 at 2:39 PM, Pierre-Arnaud Marcelot <pa@marcelot.net>wrote:

> Hi Göktürk,
>
> On 20 oct. 2011, at 13:19, 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 <elecharny@apache.org>wrote:
>
>> On 10/20/11 12:33 PM, Alex Karasulu wrote:
>>
>>> On Thu, Oct 20, 2011 at 1:18 PM, Emmanuel Lecharny<elecharny@gmail.com>*
>>> *wrote:
>>>
>>>  On 10/20/11 12:06 PM, Alex Karasulu wrote:
>>>>
>>>>  On Thu, Oct 20, 2011 at 12:43 PM, Guillaume Nodet<gnodet@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>  I think you first need to define your constraints and what you want
to
>>>>>
>>>>>> 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.
>
>
> Actually, no. It's a way to solve in an OSGI environment the class loading
> of external classes we're currently facing.
> At the moment, we have no way to provide a third party comparator for
> example. We won't be able to load the class since it's defined in another
> bundle.
>
I just meant, loading some plain jar file in classpath and referencing its
classname through some schema.ldif file. Not much like extendibility :)

>
> 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.
>
>
> Interesting. I have yet to see how it works. I have imported your patch,
> but didn't have the time to play with the code yet.
> I'm going to do this right now.
>
Code is working but remember, it only handles the comparator part. You must
get errors on syntaxcheckers first. it was Comparators throwing exceptions
first. By the way, to preserve the old tests and shared completely. I will
mode the logic out from DefaultSchemaManager class. By creating a new class.
ApacheDS will even be executable without OSGI for now.

So don't use that patch. I will slightly modify it.

>
>
>>>  If you want someone to be able to write a jar to extend the api which
>>>>> will
>>>>>
>>>>>  work in a non osgi environment and (with minimal changes) in an osgi
>>>>>> environment, go for fragments.
>>>>>>
>>>>>>  Forgive me, but the fragment approach seems like a hack. Fragments
>>>>>> were
>>>>>>
>>>>> created in OSGi to handle intractable problems with split packages
>>>>> where
>>>>> you
>>>>> had no way to merge the split. Now we're using it as a main stream
>>>>> feature
>>>>> to work around these hairy issues. Please note that I am not saying we
>>>>> should abandon it, just playing devil's advocate here. We obviously
>>>>> need
>>>>> more thought on the constraints which you've made very apparent here
in
>>>>> your
>>>>> post. Thanks for it.
>>>>>
>>>>>  Seems currently to be the only path we can use. We may ask on Felix's
>>>> mailing list to see if there is some other way, but I trust Guillaume
>>>> here.
>>>>
>>>>
>>>>  This is not a trust issue with anyone.
>>>
>> Well, when I wrote 'I trust Guillaume', that does not mean I don't trsut
>> you. It's just that I have not the background to dispute his knowledge.
>>
>>
>>  It's a matter of exploration and lack
>>> of being up to date on my part. Hope no one misinterprets my questions as
>>> a
>>> lack of trust. I'm finding discrepancies in what I learned in the past
>>> with
>>> the proposed direction today and asking about it.
>>>
>>
>> I must admit that I'm more a lurker than an actor of this discussion. I
>> can just brng some light on what we currently have, and the needs that we
>> have.
>>
>>>
>>>
>>>> can you be a bit more explicit here, for people like me who ae
>>>> semi-OSGi-agnostic ?
>>>> (damn, I *knew* I should have jumped into the OSGi wagon one year ago,
>>>> at
>>>> least... That's the problem when beig lazzy :/ )
>>>>
>>>>
>>>>  > From my limited understanding the fragments feature was created to
>>> handle
>>> situations when you had split packages but could not merge those packages
>>> because you did not have access to the code or some sh*t like that.
>>>
>>> These extensions should not be in the same package space. Those adding
>>> schema or other extensions should not be adding them into the same
>>> packages
>>> used by the API. In that case my logic leads me to the question: why use
>>> fragments?
>>>
>>>
>>>  I'm not sure that simply declaring extensions in a different package is
>> enough. It seems more like a class-loader and visibility issue in this case,
>> AFAIU.
>
> fragments outside the OSGI will give you an global class visibility. In
> OSGI they will be merged with intended host (shared-ldap-model in our case)
> and its packages will be served under its classloader. So no problem here.
> If we want to use them use them, they are not that evil. What i must say is,
> we don't have to do anything for supporting it right now. The way we load
> schema elements (classnames comes from schema ldifs) already let them work
> out of the box right now.
>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
> 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.
>
>
> Indeed, that's one thing we already tried back in February.
> I think we had to rollback this because we had no great way to correctly
> shutdown the Felix instance at the end.
> Also it was kind of heavy to have to launch a full OSGI container in order
> to use an LDAP API.
>
> Regards,
> Pierre-Arnaud
>
> Regards,
> Göktürk
>
>
>

Mime
View raw message