directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 10:33:07 GMT
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?

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.


> This is just fine to keep them as they are. We can even make them plain
> OSGi services at some point. In any case, this is a non issue.
>
>
This I agree with because it allows extension as-is. It's a clean straight
forward solution for now.


>
>> 2). LDAP Schema
>>
>> Now from what I understand enabling new schema on clients via the API is
>> the
>> main issue introducing additional constraints requiring us to consider the
>> use of fragments.
>>
>> Is this correct?
>>
> Correct, sir !
>
>
:-D


>
>> 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.


>
>> 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 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. 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.


>
>> If you want to go a cleaner osgi way, go for services, but forget about
>>
>>> class names in the schema directly, and you need to define two different
>>> ways, one for osgi and one in a non osgi environment (as you won't have
>>> osgi
>>> services at all in a flat classloader).
>>>
>>> It's all about trade-offs.
>>>
>>>
>>>  Right.
>>
> Yeah...
>
>
>
>>
>>  When talking with Emmanuel this week, it seems to me that for the api,
>>> extending the api was not a very common operation and did not really
>>> require
>>> the osgi dynamism.  Fragments are perfect for those simple use cases.
>>>
>>>  Yes but the extension should not happen in the same package. Hence we're
>> using this feature for something it was not intended for. Again just
>> pointing this out, not saying it's not ideal. Perhaps this is fact is not
>> at
>> all that important in the end.
>>
>
> 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 :/ )
>
>
Well I jumped on the wagon several times and fell off repeatedly without
concrete application opportunities to solidify this knowledge. Guillaume is
perhaps the most experienced having used OSGi practically for years now.

>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?


>
>
>>
>>  But for sure, if you ask an OSGi purist, the recommandation will be to
>>> not
>>> use fragments.
>>>
>>>
>>>  Right and maybe we should not be purists ;).
>>
>
> Purity is good for virgins. We aren't...
>
>
Heh, yeah but sometimes non-virgins like to look like virgins :-D.

-- 
Best Regards,
-- Alex

Mime
View raw message