|
From: <jue...@we...> - 2003-12-09 08:48:58
|
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 |
|
From: Colin S. <col...@ex...> - 2003-12-09 14:23:31
|
jürgen höller [werk3AT] wrote: >Everybody, > >I've reworked quite significant parts in the last couple of days, and also added a few new features: > >... > >- 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. > > > Jürgen, While I know people are always asking for the Open Session in View pattern support, I personally think it is a pretty dangerous pattern to use. As per the Hibernate docs, http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#manipulating-data-s13-4 if Session throws an exception, the Session should be closed and discarded, as it will be inconsistent. The Open Session in View pattern will work ok if the view code ensures that once a Hibernate exception is handled no more db related code is used, but since the session handling is above all the other code, it does not enforce this in any way. In fact, if the view code is calling down to some service code that does the db access itself, the view code may not even know that db access is being done. At a minimum, I recommend we annotate the Javadocs for these classes with a warning about this aspect... Regards, Colin |