The JNDI framework allows for object implementations to be loaded in dynamically via object factories. For example, when looking up a printer bound in the name space, if the print service binds printer names to References, the printer Reference could be used to create a printer object, so that the caller of lookup can directly operate on the printer object after the lookup.
An ObjectFactory is responsible for creating objects of a specific type. In the above example, you may have a PrinterObjectFactory for creating Printer objects.
For the reverse process, when an object is bound into the namespace, JNDI provides state factories. Continuing with the printer example, suppose the printer object is updated and rebound:
ctx.rebind("inky", printer);
A state factory must implement the StateFactory interface. In addition, the factory class must be public and must have a public constructor that accepts no parameters.
The getStateToBind() method of a state factory may be invoked multiple times, possibly using different parameters. The implementation is thread-safe.
StateFactory is intended for use with service providers that implement only the Context interface. DirStateFactory is intended for use with service providers that implement the DirContext interface.
NamingManager.getStateToBind() successively loads in state factories and invokes this method on them until one produces a non-null answer. DirectoryManager.getStateToBind() successively loads in state factories. If a factory implements DirStateFactory, then DirectoryManager invokes DirStateFactory.getStateToBind(); otherwise it invokes StateFactory.getStateToBind().
When an exception is thrown by a factory, the exception is passed on to the caller of NamingManager.getStateToBind() and DirectoryManager.getStateToBind(). The search for other factories that may produce a non-null answer is halted. A factory should only throw an exception if it is sure that it is the only intended factory and that no other factories should be tried. If this factory cannot create an object using the arguments supplied, it should return null.
The name and nameCtx parameters may
optionally be used to specify the name of the object being created.
See the description of "Name and Context Parameters" in
for details.
If a factory uses nameCtx it should synchronize its use
against concurrent access, since context implementations are not
guaranteed to be thread-safe.
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.