Re: [Springframework-developer] release plan

[Rod J. <rod...@in...>]

 <quote>
>What do you intend the interceptors for? Demarcating transactions via
binding a Session resp. PersistenceManager to the thread is already possible
via the TransactionInterceptor, if the correct transaction manager is used
in combination with SessionFactoryUtils resp.
PersistenceManagerFactoryUtils, or the templates that use the latter
underneath. A Hibernate Session even binds to the thread on first usage
within a JTA transaction, to enable afterCompletion synchronization. I can't
really think of any other benefits that additional interceptors might offer,
so I'm curious...
 </quote>

Interceptor simply to make available a PersistenceManager and ensure it's
closed in all cases. I find the try/catch/finally thing a pain with JDO. I
was talking to Robin Roos recently (author of the first JDO book) and he's
used servlet filters for this previously, but thought the AOP approach
sounded good. So as with transactions, the callback (template) approach is
great in many cases, but it's also nice to have a declarative alternative.

E.g. business object provides a protected getPersistenceManager() method.
The default implementation uses the Spring AOP API to get this from the
invocation. It's easy to override this at test time or to use the class
outside an AOP context.

Regards,
Rod