The JNDI framework allows for object implementations to be loaded in dynamically via object factories. See ObjectFactory for details.
A DirObjectFactory extends ObjectFactory by allowing an Attributes instance to be supplied to the getObjectInstance() method. DirObjectFactory implementations are intended to be used by DirContext service providers. The service provider, in addition reading an object from the directory, might already have attributes that are useful for the object factory to check to see whether the factory is supposed to process the object. For instance, an LDAP-style service provider might have read the "objectclass" of the object. A CORBA object factory might be interested only in LDAP entries with "objectclass=corbaObject". By using the attributes supplied by the LDAP service provider, the CORBA object factory can quickly eliminate objects that it need not worry about, and non-CORBA object factories can quickly eliminate CORBA-related LDAP entries.
Special requirements of this object are supplied
using environment.
An example of such an environment property is user identity
information.
NamingManager.getObjectInstance() successively loads in object factories and invokes this method on them until one produces a non-null answer. When an exception is thrown by an object factory, the exception is passed on to the caller of NamingManager.getObjectInstance() (and no search is made for other factories that may produce a non-null answer). An object factory should only throw an exception if it is sure that it is the only intended factory and that no other object factories should be tried. If this factory cannot create an object using the arguments supplied, it should return null.
A URL context factory is a special ObjectFactory that creates contexts for resolving URLs or objects whose locations are specified by URLs. The getObjectInstance() method of a URL context factory will obey the following rules.
obj is null, create a context for resolving URLs of the
scheme associated with this factory. The resulting context is not tied
to a specific URL: it is able to handle arbitrary URLs with this factory's
scheme id. For example, invoking getObjectInstance() with
obj set to null on an LDAP URL context factory would return a
context that can resolve LDAP URLs
such as "ldap://ldap.wiz.com/o=wiz,c=us" and
"ldap://ldap.umich.edu/o=umich,c=us".
obj is a URL string, create an object (typically a context)
identified by the URL. For example, suppose this is an LDAP URL context
factory. If obj is "ldap://ldap.wiz.com/o=wiz,c=us",
getObjectInstance() would return the context named by the distinguished
name "o=wiz, c=us" at the LDAP server ldap.wiz.com. This context can
then be used to resolve LDAP names (such as "cn=George")
relative to that context.
obj is an array of URL strings, the assumption is that the
URLs are equivalent in terms of the context to which they refer.
Verification of whether the URLs are, or need to be, equivalent is up
to the context factory. The order of the URLs in the array is
not significant.
The object returned by getObjectInstance() is like that of the single
URL case. It is the object named by the URLs.
obj is of any other type, the behavior of
getObjectInstance() is determined by the context factory
implementation.
The name and environment parameters are owned by the caller. The implementation will not modify these objects or keep references to them, although it may keep references to clones or copies.
Name and Context Parameters.
The name and nameCtx parameters may
optionally be used to specify the name of the object being created.
name is the name of the object, relative to context
nameCtx.
If there are several possible contexts from which the object
could be named -- as will often be the case -- it is up to
the caller to select one. A good rule of thumb is to select the
"deepest" context available.
If nameCtx is null, name is relative
to the default initial context. If no name is being specified, the
name parameter should be null.
If a factory uses nameCtx it should synchronize its use
against concurrent access, since context implementations are not
guaranteed to be thread-safe.
Special requirements of this object are supplied
using environment.
An example of such an environment property is user identity
information.
DirectoryManager.getObjectInstance() successively loads in object factories. If it encounters a DirObjectFactory, it will invoke DirObjectFactory.getObjectInstance(); otherwise, it invokes ObjectFactory.getObjectInstance(). It does this until a factory produces a non-null answer.
When an exception is thrown by an object factory, the exception is passed on to the caller of DirectoryManager.getObjectInstance(). The search for other factories that may produce a non-null answer is halted. An object factory should only throw an exception if it is sure that it is the only intended factory and that no other object factories should be tried. If this factory cannot create an object using the arguments supplied, it should return null.
Since DirObjectFactory extends ObjectFactory, it effectively has two getObjectInstance() methods, where one differs from the other by the attributes argument. Given a factory that implements DirObjectFactory, DirectoryManager.getObjectInstance() will only use the method that accepts the attributes argument, while NamingManager.getObjectInstance() will only use the one that does not accept the attributes argument.
See ObjectFactory for a description URL context factories and other properties of object factories that apply equally to DirObjectFactory.
The name, attrs, and environment parameters are owned by the caller. The implementation will not modify these objects or keep references to them, although it may keep references to clones or copies.