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:06:39 GMT
On 10/20/11 11:43 AM, Guillaume Nodet wrote:
> I think you first need to define your constraints and what you want to focus
> on.
> 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.
> 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.
> 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.   But
> for sure, if you ask an OSGi purist, the recommandation will be to not use
> fragments.

We have two different needs :
1) provide a OSGi compliant server, including an OSGi container for 
those who don't have one. That means we include Felix, and we will have 
a mode that let the user set his own container, excluding Felix in this 
case. We will have to provide two launchers to cover those two different 
In any case, all the extension points will be plain OSGi services.
2) For the API, this is a different story, as the API will most 
certainly be used outside an OSGi container, except for ADS and Studio, 
which will run into Felix (ADS) and Equinox (Studio). The extension 
points will be plain java classes, class-loaded using their FQCN or even 
loading the bytecode stored in an entry.

This is somehow what we discussed with Guillaume yesterday, and I do 
think that fragments are a good trde-off for the API.

At least, it seems to work...

Emmanuel L├ęcharny

View raw message