Previous | Next | Trail Map | Beyond the Basics | What's in a Name?

Dynamic Name Composition

For name composition, you typically use the methods in the Name(in the API reference documentation) interface. The Composite Names section explained how to add components to a composite name and the Compound Names section. discussed how to add components to a compound name.

These methods are useful when you know that you are dealing with either composite names or compound names. But what if you have a composite name and you need to add a component? Would you use the composite name syntax or the compound name syntax? If compound, which compound name syntax? Developers who write applications such as namespace browsers often face this question. It can be difficult to answer without a lot of insight and knowledge about the context in which the name is bound and how it was resolved.

For example, suppose that the name "cn=homedir,cn=Jon Ruiz,ou=People" is bound to an object in a different naming system--specifically, a file system context. To add a filename component to this name, you use the composite name syntax. This is because you are traversing from an LDAP namespace to the file namespace.

cn=homedir,cn=Jon Ruiz,ou=People/tutorial
When you add yet another filename component to the result, you should use the filename syntax. For example, in Windows, adding the component "report.txt" results in the name:
cn=homedir,cn=Jon Ruiz,ou=People/tutorial\report.txt
To add an LDAP component to the name "cn=Jon Ruiz, ou=People" you would use the LDAP name syntax.
cn=homedir,cn=Jon Ruiz,ou=People
In all three examples, you use a different naming syntax. The rules of when to use which syntax become difficult to figure out, as well as to program.

To assist in this task, the JNDI provides Context.composeName()(in the API reference documentation) for composing names dynamically depending on federated namespace boundaries. You give this method two arguments: the name that you want to append and the name of this context (relative to one of its ancestor contexts). You need to supply the latter because, in general, a context does not know its name, especially its name relative to other contexts through which you might have resolved to get there.

The implementation of this method is supplied by the service provider. This puts the onus of figuring out namespace boundaries and which naming syntax to use on the service provider instead of the application developer.

Following is an example that performs the compositions described here.

// Create the initial context
Context ctx = new InitialContext(env);

// Compose a name within the LDAP namespace
Context ldapCtx = (Context)ctx.lookup("cn=Jon Ruiz,ou=people");
String ldapName = ldapCtx.composeName("cn=homedir", "cn=Jon Ruiz,ou=people");

// Compose a name when it crosses into the next naming system
Context homedirCtx = (Context)ctx.lookup(ldapName);
String compositeName = homedirCtx.composeName("tutorial", ldapName);

// Compose a name within the File namespace
Context fileCtx = (Context)ctx.lookup(compositeName);
String fileName = fileCtx.composeName("report.txt", compositeName);
The names of the variables used in this example are only for illustrative purposes. The application does not need to know whether it is interacting with an LDAP context, a file system context, or a context that connects the two.

Note: The v1.2 Beta version of the file system service provider does not implement composeName() properly. If you run this example on a Windows platform, then the last filename composition uses a forward slash character ("/") instead of a backslash character.

This method also has an overloaded form that accepts Name instead of java.lang.String arguments. If you use the Name form, then make sure that both arguments are of the same type. For example, don't mix a CompositeName with a CompoundName.

What's in a Name?: End of Lesson

What's next? Now you can:

Previous | Next | Trail Map | Beyond the Basics | What's in a Name?