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.

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

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.

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. 

This should serious remove some ugly and dangerous code we've got at this point in the LDAP API.

Thoughts?

Thanks,
Alex

On Wed, May 11, 2011 at 6:14 PM, Alex Karasulu <akarasulu@apache.org> wrote:


On Wed, May 11, 2011 at 6:03 PM, Guillaume Nodet <gnodet@gmail.com> wrote:
What we've done for  Camel for example is to allow those libraries to
leverage OSGi if deployed in OSGi and default to a basic mode in other
cases.

For Camel, components can be create by users (though I guess it's the
same here, not average users).  Camel can discover components using a
pluggable discovery mechanism.  When deployed in OSGi, Camel
automatically select an OSGi aware discovery mechanism that will be
able to look into existing bundles for such components (well, it's in
reality slightly more complicacted, but thats the idea).   When in a
non OSGi environement, the default discovery mechanism just scans for
META-INF/services/xxx which define camel components.

The idea here is that if the user wants to use OSGi, he'll be able to
use the OSGi modularity layer and dynamism to deploy things at runtime
and all the OSGi goodness.   Else, we just use a very simple and basic
things that works very nicely in a flat classloader.


That sounds very reasonable to me. This is the best path. Thanks Guillaume for helping us see this clearly.