directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [LDAP API] Codec extension mechanism direction (WAS: Re: OSGi startup and shutdown problems)
Date Wed, 11 May 2011 15:56:51 GMT
On 5/11/11 5:35 PM, Alex Karasulu wrote:
> Hi dev peeps,
>
> So after a long thread I just wanted to summarize the realizations and
> conclusions so we can set a clear direction for managing the codec extension
> mechanism. I created a separate clean thread for this here with Guillaume's
> core recommendation following.
>
> For the sake of speed I will define a direction and people can opine:
>
> 1). Expose a means in the LDAP API (really SPI) to have codec extensions
> programmatically registered. I this already exists.

+1
> 2). Remove the standalone codec factory implementation that starts up Felix.

Ok, that would be a relief.
> 3). Add a simple ClassLoader component to be used in standalone mode to load
> the plugin classes (from the plugin bundles defaulting to regular jars
> presumed to be on the classpath). Some configuration information drives how
> this component discovers what plugin classes to attempt to class load.
Ok, fine.
> 4). Set it up so by default, the LDAP API uses the simple ClassLoader based
> discover/load/register mechanism. In an OSGi environment this is disabled to
> enable plugins to self register.
Ok.
> This should serious remove some ugly and dangerous code we've got at this
> point in the LDAP API.
Absolutely.

Question : are we sure that teh API will continue to work in Studio, 
using Equinox ? And are we sure we will be able to have felix started in 
ApacheDS ?

That raises another related issue for ADS : what if an application is 
already using an OSGi framework and wants to embed ADS ?

Thanks !

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


Mime
View raw message