directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 11:05:51 GMT
On 20 oct. 2011, at 12:33, 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 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.

Controls and extended operations should be extensible by users of the API.
Same thing for Schema elements (like comparators, normalizers, syntax checkers, etc.)

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

We need to have a solution which works with or without an OSGI container.

> 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

Given my small experiment, it seems to do the trick (I've tested it on smaller use-case/environment).
But, it may not be the best solution or there may be other solutions to achieve this.

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

Guillaume can correct me here if I'm wrong but, there should be absolutely no issue with package
One of the examples for the use of fragments is localization.
You could have a specific fragment for each language containing the properties file with the
proper string translations.
Each fragment is independent and can be added without requiring a release of the original
host bundle (which contains the code).
Everything being under the same package (of course splitted into the different bundles).

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

I won't add anything to that part of the discussion... ;) :p


> -- 
> Best Regards,
> -- Alex

View raw message