directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject [LDAP API] Codec extension mechanism direction (WAS: Re: OSGi startup and shutdown problems)
Date Wed, 11 May 2011 15:35:20 GMT
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.
>

Mime
View raw message