directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 10:58:55 GMT
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.
>
>
>>> 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.

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message