[Springframework-developer] Reworkings and new features

[<jue...@we...>]

Everybody,
=20
I've reworked quite significant parts in the last couple of days, and =
also added a few new features:
=20
- I've dissolved support for ContextOptions, "config" objects exposed to =
the ServletContext, and UrlAwareHandler. They were all effectively =
undocumented and assumably completely unused.
=20
- WebApplicationContext initialization works via a =
ConfigurableWebApplicationContext interface now, instead of via =
constructor requirements (actually, this a second attempt: there have =
been separate interfaces for root and nested web application contexts =
last week). ConfigurableWebApplicationContext supports a =
"configLocations" property, to be able to override the default locations =
with specific ones. FrameworkServlet is able to drive this via its new =
"contextConfigLocation" property, potentially with multiple config files =
per servlet. XmlWebApplicationContext's and =
StaticWebApplicationContext's initialization procedure is completely =
reworked towards this.
=20
- I've introduced support for WebWork/Maverick-style "throwaway =
controllers", in addition to our existing Servlet/Struts-style reusable =
controllers. ThrowawayController and ValidatableThrowawayController in =
the web.servlet.mvc.throwaway package serve both as command and =
controller: They get populated with request parameters themselves and =
have execute methods to determine a ModelAndView - being completely =
unaware of the Servlet API. Obviously, they need to be defined as =
prototype beans in the DispatcherServlet context. As they have their own =
HandlerAdapters, they are very simply to set up, as they don't require =
Controller wrappers around them. Their main advantage as I see it =
testability: no need for Servlet API mocks for testing them, just like =
with WebWork actions. If you do need the Servlet API or more =
sophisticated workflows like session form objects, our "classic" =
controllers are the way to go.
=20
- I've added support for the "Open Session in View" pattern with =
Hibernate: OpenSessionInViewInterceptor is a HandlerInterceptor for =
Spring's web MVC, OpenSessionInViewFilter a generic Servlet 2.3 Filter. =
Both can simply be used together with HibernateTransactionManager or =
JtaTransactionManager: The latter will automatically detect the =
pre-bound Sessions and leave their lifecycle management to the original =
binder. In the course of implementing OpenSessionInViewFilter, I've also =
added generic Filter base classes, namely GenericFilterBean and =
OncePerRequestFilter. Those classes are now also used for =
MultipartFilter.
=20
- I've restructured the internals of the jdbc package: The JDBC-specific =
DataAccessException subclasses are now in the root jdbc package; =
SQLExceptionTranslator and associated classes are now in jdbc.support; =
the DataFieldMaxValueIncrementer stuff is in jdbc.support.incrementer. =
I've reworked the former QueryExecutor into the more generic =
NativeJdbcExtractor, in jdbc.support.nativejdbc: an abstraction to =
retrieve native JDBC objects from a connection pool that returns wrapped =
objects, with out-of-the-box SimpleNativeJdbcExtractor and =
CommonsDbcpNativeJdbcExtractor. A new feature is BlobCreator in =
jdbc.support.lob, with out-of-the-box DefaultBlobCreator and =
OracleBlobCreator.
=20
Please try your apps on the current CVS version, and possibly have a =
look at the new features. Feedback *before* the M4 release is very =
welcome :-)
=20
Juergen