New Java and JavaDoc TextMate bundles

Finally, I got the new Java and JavaDoc TM bundles up to scratch and got them promoted from review.

If you are using TM for Java, you'll want to update your bundle.

Moving/Replacing entries with Gldapo 0.7

Following on from the previous post, Gldapo 0.7 makes dealing with the location of LDAP objects much easier. This impacts the move() and replace() methods. I'll focus on replace() here, but pretty much everything applies to move().

0.7 introduces a new signature of replace(String namingValue, Object parent). Let's look at some usage then I'll explain.

What we want to do here is replace an object with cn=Luke and sn=Daily with an object with sn=Daley (note: we could do this with a search, mod, save admittedly, but this is just an example).

I am using the person schema class from the previous post.

First, 0.6 style…

def p = new Person(
    cn: "Luke",
    sn: "Daley"
)
 
p.replace("cn=Luke")

In 0.7…

def p = new Person(
    sn: "Daley"
)
 
p.replace("Luke", null)

Or…

def p = new Person(
    cn: "Luke",
    sn: "Daley"
)
 
p.replace()

Because we now know which attribute defines the name, we don't need to duplicate that information in the replace() call.

The second argument to replace(String,Object) is the parent of the object to replace. Say we wanted to replace an object in a different ou…

p.replace("Luke", "ou=people")

The move(String,Object) method follows similar semantics. Note though that there is no move() method, cause that just wouldn't make sense.

@GldapoNamingAttribute

I've been working on making the way you define the location of an entry object better.

In Gldapo 0.6, this is a bit cumbersome. Let's look at some examples. Here is our schema class in 0.6…

class Person
{
    String cn
    String sn
}

So let's create one of these people in an ou called people…

def p = new Person(
    cn: "Luke"
    sn: "Daley"
    rdn: "cn=Luke,ou=people"
)
p.save()

Obviously, that could be better.

Let's take a look at how this has improved. First of all our schema class redone…

class Person
{
    @GldapoNamingAttribute
    String cn
    String sn
}

And the same create…

def p = new Person(
    cn: "Luke"
    sn: "Daley"
    parent: "ou=people"
)
p.save()

So what has happened?

The @GldapoNamingAttribute annotation

In 0.7, all schema classes must annotate one attribute with @GldapoNamingAttribute. It is a bit of an inconvenience if you never really care about where the object is (say if you are just using Gldapo for authentication), but it does weigh in with significant advantages.

The parent property

The parent property is new in 0.7. It returns a DistinguishedName that is the entry above the entry, relative to the entry's directory.

So the primary way to set an entry's location is to use a combination of setting the objects naming attribute and the parent attribute.

Using rdn

The rdn attribute still exists (though it's name may change before release) and is even improved. You could also create the person like this…

def p = new Person(
    sn: "Daley"
    rdn: "cn=Luke,ou=people"
)
p.save()

That will work just fine. The rdn property is also gettable on objects that were defined using a naming attribute value and a parent.

You must however match the naming attributes. For example, this won't work…

def p = new Person(
    sn: "Daley"
    rdn: "uid=Luke,ou=people"
)
p.save()

This will complain about trying to set a naming attribute called uid, when cn is defined as the attribute.

Note: All these examples assume only one directory is defined, therefore there is no need to specify which directory the entry belongs to when creating.

The current snapshot of Gldapo has this new feature.