FactoryBean that creates a
JDO PersistenceManagerFactory. This is the usual way to
set up a shared JDO PersistenceManagerFactory in a Spring application context;
the PersistenceManagerFactory can then be passed to JDO-based DAOs via
dependency injection. Note that switching to a JNDI lookup or to a bean-style
PersistenceManagerFactory instance is just a matter of configuration!

NOTE: This class requires JDO 2.0 or higher, as of Spring 2.5.
Since JDO 2.1, it will also expose the JPA EntityManagerFactory
as long as the JDO provider creates a JDOEntityManagerFactory reference
underneath, which means that this class can be used as a replacement for
LocalEntityManagerFactoryBean in such a scenario.

Configuration settings can either be read from a properties file,
specified as "configLocation", or locally specified. Properties
specified as "jdoProperties" here will override any settings in a file.
On JDO 2.1, you may alternatively specify a "persistenceManagerFactoryName",
referring to a PMF definition in "META-INF/jdoconfig.xml"
(see setPersistenceManagerFactoryName(java.lang.String)).

This class also implements the
PersistenceExceptionTranslator
interface, as autodetected by Spring's
PersistenceExceptionTranslationPostProcessor,
for AOP-based translation of native exceptions to Spring DataAccessExceptions.
Hence, the presence of a LocalPersistenceManagerFactoryBean automatically enables
a PersistenceExceptionTranslationPostProcessor to translate JDO exceptions.

As alternative to the properties-driven approach that this FactoryBean offers
(which is analogous to using the standard JDOHelper class with a Properties
object that is populated with standard JDO properties), you can set up an
instance of your PersistenceManagerFactory implementation class directly.

Like a DataSource, a PersistenceManagerFactory is encouraged to
support bean-style configuration, which makes it very easy to set up as
Spring-managed bean. The implementation class becomes the bean class;
the remaining properties are applied as bean properties (starting with
lower-case characters, in contrast to the corresponding JDO properties).

Note that such direct setup of a PersistenceManagerFactory implementation
is the only way to pass an external connection factory (i.e. a JDBC DataSource)
into a JDO PersistenceManagerFactory. With the standard properties-driven approach,
you can only use an internal connection pool or a JNDI DataSource.

The close() method is standardized in JDO; don't forget to
specify it as "destroy-method" for any PersistenceManagerFactory instance.
Note that this FactoryBean will automatically invoke close() for
the PersistenceManagerFactory that it creates, without any special configuration.

Subclasses can override this to perform custom initialization of the
PersistenceManagerFactory instance, creating it via the given Properties
that got prepared by this LocalPersistenceManagerFactoryBean.

Method Detail

setPersistenceManagerFactoryName

This may either be a properties resource in the classpath if such a resource exists
(JDO 2.0), or a PMF definition with that name from "META-INF/jdoconfig.xml" (JDO 2.1),
or a JPA EntityManagerFactory cast to a PersistenceManagerFactory based on the
persistence-unit name from "META-INF/persistence.xml" (JDO 2.1 / JPA 1.0).

Default is none: Either 'persistenceManagerFactoryName' or 'configLocation'
or 'jdoProperties' needs to be specified.

newPersistenceManagerFactory

Subclasses can override this to perform custom initialization of the
PersistenceManagerFactory instance, creating it for the specified name.

The default implementation invokes JDOHelper's
getPersistenceManagerFactory(String) method.
A custom implementation could prepare the instance in a specific way,
or use a custom PersistenceManagerFactory implementation.

Parameters:

name - the name of the desired PersistenceManagerFactory

Returns:

the PersistenceManagerFactory instance

See Also:

JDOHelper.getPersistenceManagerFactory(String)

newPersistenceManagerFactory

Subclasses can override this to perform custom initialization of the
PersistenceManagerFactory instance, creating it via the given Properties
that got prepared by this LocalPersistenceManagerFactoryBean.

The default implementation invokes JDOHelper's
getPersistenceManagerFactory(Map) method.
A custom implementation could prepare the instance in a specific way,
or use a custom PersistenceManagerFactory implementation.

Parameters:

props - the merged properties prepared by this LocalPersistenceManagerFactoryBean

getObjectType

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.

isSingleton

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.