On Wed, May 11, 2011 at 6:56 PM, Emmanuel Lecharny <firstname.lastname@example.org> wrote:
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.
Ok, that would be a relief.
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.
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 ?
Actually I think it is using equinox at the present moment. If I remember correctly we're not using the standalone mechanism when in the eclipse environment. PAM I think found a way to get the bundle loaded under eclipse OSGi (a.k.a. equinox). Might want to get confirmation from PAM though.
That raises another related issue for ADS : what if an application is already using an OSGi framework and wants to embed ADS ?
That's not a problem since basically they can load just the bundles. We can carry ApacheDS with installers inside Karaf with our standalone distribution. Those loading ADS into an existing environment need only issue a load from the bundle repository. I think there's some magic there making your local maven repository into an OSGi bundle repository. I wonder if Karaf knows how to pull bundles down too from remote repositories, I bet Guillaume can answer that :).