directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 10:18:02 GMT
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 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. 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.
> 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 !
> 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 !
> 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() )
> 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.
> 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.

>> 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 :/ )

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

Emmanuel L├ęcharny

View raw message