directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: LDAP Controls
Date Tue, 01 Mar 2005 21:39:01 GMT
David Boreham wrote:

> Heads up on one thing we're working on here:
> We're writing a new Backend class.
> It needs to implement special behavior depending on the presence and 
> value of an LDAP control
> attached to the operation request PDU.

Presently there is no support in the LDAP line protocol code.  Meaning 
the controls are not included in the Request/Response.  Yeah 
disappointing I know.  We can get it in there quickly though.

> The current code doesn't seem to allow easy access
> to the LDAP controls from inside a back end (the
> JNDI controls class doesn't handle arbitrary
> controls, I believe).

I was wondering that myself.  After looking at the javadocs I think its 
actually only capable of handling arbitrary controls.  Here's why ...

First because it's an interface so it must be implemented.   It only 
contains the 3 general property accessor methods that apply to all controls:

String getID() ==> gets the control's OID
boolean isCritical() ==> the criticality
byte[] getEncodedValue() ==> the ASN.1 BER encoded representation of the 

So this covers the full gambit of controls.  We just need to implement 
them and perhaps give implementations nice decoded accessors.  Let the 
control know how to (decode) handle access to its elements.  This may 
not be that easy to do.  I think our approach in the line protocol side 
that handles the decoding can help out.  We know that controls must be 
registered and cannot be adhoc: supported controls must be present 
within the RootDSE.

We can easiler decode and populate registered controls that still 
implement this JNDI Control interface.  They simply have control 
specific accessors to the decoded elements of the control whatever they 
may be.  This way the control is pumped into the server side JNDI 
context and eventually the methods on a backend to access the control.  
Based on the OID the controls can be cast into the implementation type 
to access control specific information.

> Anyway, at present we're hacking the controls
> object that comes with the Request into the env Map
> that's passed to the back end 's search method.
> That should work for what we need to do,
> but it's an evil hack.
> I was wondering what the plans are for things like this?

Well I thought controls would come up and I was looking for someone to 
pick up the torch here.  Lead us to an overall approach for them.  I 
have some ideas though.  Above I mentioned some of them.

> Typically one sees a catch-all 'context' or 'session' object
> that's passed in every call, that allows code anywhere to
> get at things like the authId for the current operation,
> things like that, with accessor methods. Such an object could also be 
> used
> to access controls (and also write response controls
> back onto the response).

I think we can do that with the context through additions to the 
environment and properties.

> I realize this isn't great 'object design perfection',
> but OTOH it's a real pain to be always finding that
> there's no way to get the @*@#^ thing that you
> need in your code 15 levels down the stack from
> where it was last seen...
I know what you mean.  Perhaps we can use a ThreadLocal to hold a 
reference to the context associated with the operation.  What do you think?

> The particular example at hand is a syncronization
> control that carries an update vector used in the
> back-end to determine the set of entries modified
> since that update vector was generated.
So this is list a control for batching updates?  Is this a published 
control or one you devised - just curious?

> Another example would be indexed VLV searches, where
> the back-end needs access to the VLV control payload
> to drive its query execution engine.

Hmmm good point.  So let me just ask directly once again so I understand 
this correctly.  You're saying the Controls are not available to you 
because the context is not available within your backend partition?


View raw message