Before:
- new GenericXmlApplicationContext("com/acme/path/to/resource.xml");
- GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("com/acme/path/to/resource.xml");
ctx.refresh();
After:
- The above remain supported, as well as new class-relative variants
- import com.acme.path.to.Foo;
new GenericXmlApplicationContext(Foo.class, "resource.xml");
- import com.acme.path.to.Foo;
GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load(Foo.class, "resource.xml");
ctx.refresh();
These changes are generally aligned with signatures long available in
ClassPathXmlApplicationContext. As GenericXmlApplicationContext is
intended to be a more flexible successor to CPXAC (and FSXAC), it's
important that all the same conveniences are available.
GenericApplicationContext and AbstractRefreshableApplicationContext
implementations now call DefaultListableBeanFactory.setSerializationId()
only upon successful refresh() instead of on instantiation of the
context, as was previously the case with GAC.
DLBF.setSerializationId() adds the beanFactory to the *static*
DLBF.serializableFactories map, and while calling close() on the
application context removes entries from that map, it does so only if
the context is currently active (i.e. refresh() has been called).
Also, cancelRefresh() has been overridden in GAC just as it has been
in ARAC to accomodate the possibility of a BeansException being thrown.
In this case, the beanFactory serializationId will be nulled out and
the beanFactory removed from the serializableFactories map.
The SerializableBeanFactoryMemoryLeakTests test case provides full
coverage of these scenarios.
Hibernate validator had been updated to 4.1.0 in the ivy metadata, but
not yet reflected in the .classpath file. The pom.xml had been updated
but there was a typo - scope read 'coompile', instead of 'compile'.
Juergen Hoeller
Chris Beams
Ben Hale
Arjen Poutsma
David Syer