directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Shared] [LDAP] Pluggable Controls and Extended Operations
Date Wed, 26 Jan 2011 12:28:22 GMT
On Wed, Jan 26, 2011 at 12:42 PM, Pierre-Arnaud Marcelot
<> wrote:
> On 26 janv. 2011, at 05:51, Alex Karasulu wrote:
>> Hi y'all,
>> So the big question is: How do we make Controls pluggable in the codec?
>> But first the other question of, "WHY bother?" was briefly mentioned
>> in another email. I will recap and clarify more here. It's clients
>> using the codec that really need pluggable controls and extended
>> operations. We cannot implement all the controls and extended
>> operations users of the client API will need or conceive of. So the
>> client must be extensible by allowing new controls and extended
>> operations to be defined. To make the client extensible this way, the
>> codec must have a plugin mechanism to be able to encode/decode new
>> control and extended operations.
>> What about the server?
>> ===================
>> The server may be more hard coded, since its out-of-the-box standard
>> LDAP request handlers must contain handling logic to process common
>> controls. If standard request handlers are made pluggable as well,
>> then these can be replaced to handle controls we have not thought
>> about. The server does not hard code extended requests since it's got
>> a handler mechanism to manage that, although how good the mechanism
>> is, is yet another question.
>> Techniques For Plugging in Controls and Extended Ops
>> =============================================
>> OSGi is great here but we're not ready to run in the environment yet.
>> Regardless though we can create an instance of Felix inside the codec
>> just to make controls and extended operations pluggable. But I don't
>> know how crazy a thought this is.
> Indeed it could be a first step, instead of moving the whole server to OSGI.
>> In the vanilla configuration I'd go with something simple that does
>> not conflict with the OSGi path. There can be a registration
>> mechanism, where "SOMETHING" registers, new controls and extended
>> operations with the codec. The codec will have to manage these
>> registrations and leverage them to instantiate new control and
>> extended request objects needed for encoding and decoding operations.
>> I said "SOMETHING" above since this could be a bundle activator in the
>> OSGi environment packaged into control and extended operation bundles,
>> or a separate piece of code in the vanilla JSE environment that with
>> configuration information loads jars from some path, specifically
>> loading certain classes for controls/extended ops and registering them
>> with the codec. We should isolate this registration code so when/if we
>> switch over to the OSGi environment this functionality can be
>> jettisoned easily. I'm thinking we might be better off just embedding
>> an OSGi container (Felix) into the client. Felix for example is not
>> that big size wise, we don't have to write more yuky code that gets
>> thrown away later, and we gain some experience while enabling these
>> extension points without impacting code above it.
> Sounds like a good idea to me.
> We could also use Karaf as OSGI container. I remember Guillaume Nodet offered his help
in that area in a previous thread on the ML (not long ago).

I definitely would like to take Guillaume up on his offer however
Karaf is not really an OSGi container, rather it is a container for
OSGi containers. It's an environment between the containers running in
it an the OS which adds some really nice benefits: for example it
offers an OSGi shell that you can remotely log into via SSH to manage
your containers and their bundles. I love it.

Ultimately we probably want to run the server inside Felix, running
inside Karaf. Using Karaf however is not an option for studio or a
simple client API.

My thought was to programmatically start up an instance of Felix
within the codec just to enable pluggable controls and extended
operations between now and when we go full OSGi. If this codec,
embedding Felix, runs in a simple Java application, or yet in another
Felix instance, or in Eclipse there's little to no impact. Plus it
gives us a tiny taste of what we can do before running everything in
an OSGi container.

>> Regardless of how we choose to solve this, these pluggable codec
>> "elements" need to implement well defined interfaces and conform in
>> behavior to some expected policy (semantic behavior). We already have
>> a lot of these interfaces defined inside the codec. It's basically a
>> codec SPI. We just need to formalize, and organize it better.
>> Any thoughts on this approach? Or do any alternative approaches come to mind?
> I think it's forth trying and we could probably code a small prototype for this to see
if it suits our needs.

Yeah we can test it out. That's probably best.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message