FactoryBean that looks up a
JNDI object. Exposes the object found in JNDI for bean references,
e.g. for data access object's "dataSource" property in case of a
The typical usage will be to register this as singleton factory
(e.g. for a certain JNDI-bound DataSource) in an application context,
and give bean references to application services that need it.
The default behavior is to look up the JNDI object on startup and cache it.
This can be customized through the "lookupOnStartup" and "cache" properties,
using a JndiObjectTargetSource underneath. Note that you need to specify
a "proxyInterface" in such a scenario, since the actual JNDI object type is not
known in advance.
Of course, bean classes in a Spring environment may lookup e.g. a DataSource
from JNDI themselves. This class simply enables central configuration of the
JNDI name, and easy switching to non-JNDI alternatives. The latter is
particularly convenient for test setups, reuse in standalone clients, etc.
Note that switching to e.g. DriverManagerDataSource is just a matter of
configuration: Simply replace the definition of this FactoryBean with a
public void setExposeAccessContext(boolean exposeAccessContext)
Set whether to expose the JNDI environment context for all access to the target
object, i.e. for all method invocations on the exposed object reference.
Default is "false", i.e. to only expose the JNDI context for object lookup.
Switch this flag to "true" in order to expose the JNDI environment (including
the authorization context) for each method invocation, as needed by WebLogic
for JNDI-obtained factories (e.g. JDBC DataSource, JMS ConnectionFactory)
with authorization requirements.
public void setDefaultObject(java.lang.Object defaultObject)
Specify a default object to fall back to if the JNDI lookup fails.
Default is none.
This can be an arbitrary bean reference or literal value.
It is typically used for literal values in scenarios where the JNDI environment
might define specific config settings but those are not required to be present.
Return the type of object that this FactoryBean creates,
or null if not known in advance.
This allows one to check for specific types of beans without
instantiating objects, for example on autowiring.
In the case of implementations that are creating a singleton object,
this method should try to avoid singleton creation as far as possible;
it should rather estimate the type in advance.
For prototypes, returning a meaningful type here is advisable too.
This method can be called before this FactoryBean has
been fully initialized. It must not rely on state created during
initialization; of course, it can still use such state if available.
NOTE: Autowiring will simply ignore FactoryBeans that return
null here. Therefore it is highly recommended to implement
this method properly, using the current state of the FactoryBean.
Is the object managed by this factory a singleton? That is,
will FactoryBean.getObject() always return the same object
(a reference that can be cached)?
NOTE: If a FactoryBean indicates to hold a singleton object,
the object returned from getObject() might get cached
by the owning BeanFactory. Hence, do not return true
unless the FactoryBean always exposes the same reference.
The singleton status of the FactoryBean itself will generally
be provided by the owning BeanFactory; usually, it has to be
defined as singleton there.
NOTE: This method returning false does not
necessarily indicate that returned objects are independent instances.
An implementation of the extended SmartFactoryBean interface
may explicitly indicate independent instances through its
SmartFactoryBean.isPrototype() method. Plain FactoryBean
implementations which do not implement this extended interface are
simply assumed to always return independent instances if the
isSingleton() implementation returns false.
The default implementation returns true, since a
FactoryBean typically manages a singleton instance.