Thursday, January 13, 2011

Behavior of the OVD "Entry" class

As part of a demo I'm doing this week I wrote a custom OVD adapter and (for various reasons) included my own logic to cache the results between LDAP calls. Along the way I discovered behavior that perplexed me and probably shortened my life by days thanks to how high my blood pressure went.

If you ever find yourself thinking things are going "just swell" on a PoC you should try using an API you've never seen before on a product you've barely used, but wait until the last day to start.

yes, my own fault. And yes it's humbling.

What I hope to save you from discovering the hard way is that OVD's class com.octetstring.vde.Entry can't be shared across calls into the directory.


What I mean is that I wrote a method that looks something like:
public void myCache.insert( Entry entry) {
  myMap.put( entry.getName().toString(), entry );
}

and called it during the first search of the directory that found the user. Then later on I tried to retrieve it by doing:
public Entry myCache.get( String key ) {
  if ( !myMap.contains( key ) )
    return null;

  Entry e =myMap.get( key );
  logger.debug( "Got entry with name " + e.getName().toString() );
  return e;
}

And I'd get back an entry and even get its name. But the Entry was always empty.
I really thought I was losing it.
My epiphany came at Zero-Dark-hundred when I changed my insert to
myMap.put( entry.getName().toString(), entry.getAsByteArray() );

and my retrieval to
Entry e = new Entry( myMap.get( key ) );
and suddenly everything started working.

I haven't gone and looked into the actual OVD code for Entry, but I'm guessing it does something super clever that I'm too dense understand at 3 in the morning.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.