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
|