dpHibernate 2.0-RC1 was posted a few weeks back.
One of the features this offers is better “offical” support for Spring 2.5.x and Spring 3.0, through extension projects.
In doing this, dpHibernate is now significantly more extensible, by having all the various dependencies wired in at runtime, allowing developers to wire in their own components if required.
However, the current implementation is very verbose in the amount of boiler-plate wiring required to get dpHibernate up-and-running. This example illustrates my point nicely.
In the future, I plan on building out a much better support for sensible defaults in the Spring configuration.
Tonight I committed the first step in this on the 2.0 branch – adding support for auto-detecting pre/post update interceptors.
Now, all the wiring required for adding Pre/Post update interceptors is handled using Spring’s existing @Component interface. Eg:
<bean id="objectChangeUpdater" class="org.dphibernate.persistence.state.AuthenticatedObjectChangeUpdater" scope="prototype"> <property name="preProcessors" ref="dpHibernatePreProcessors" /> <property name="postProcessors" ref="dpHibernatePostProcessors" /> </bean> <!-- Used in update process, for resolving proxies back to the entity --> <bean id="hibernateProxyResolver" class="org.dphibernate.persistence.state.DbProxyResolver" scope="prototype"> <constructor-arg ref="sessionFactory" /> </bean> <!-- Optional. Pre processors are invoked before an update operation. Must implement IChangeMessageInterceptor --> <util:list id="dpHibernatePreProcessors"> <ref bean="uniqueUsernameInterceptor" /> </util:list> <!-- Optional. Post processors are invokes after an update operation. Must implement IChangeMessageInterceptor --> <util:list id="dpHibernatePostProcessors"> <ref bean="passwordEncryptionInterceptor" /> </util:list> <!-- An example of a customized message interceptor. CHecks to see if a username is unique in the database before performing an Create or Update on the ApplicationUser --> <bean id="uniqueUsernameInterceptor" class="com.mangofactory.pepper.service.interceptors.UsernameExistsChangeMessageInterceptor" autowire="constructor" />
All the above XML is replaced by simply adding the @Component declaration to the top of your interceptors:
@Component public class UsernameExistsChangeMessageInterceptor implements IPreUpdateInterceptor
- You can still declare the interceptor beans themselves in the XML config if you prefer. These will be detected along with any interceptors annotated with the @Component annotation.
- You can override this behaviour by explicitly wiring in the preProcessors and postProcessors if you choose. The autowired values are only used if the value has not been explicitly set.
- In order to be eligible for autowiring, your interceptors must implement either IPreUpdateInterceptor or IPostUpdateInterceptor. These are two new interfaces, both which subclass IChangeMessageInterceptor. They don’t add any new methods, merely serve as a marker interface to indicate when in the lifecycle of the update they should be used.
- For any of this to work, you need to be using the <context:component-scan /> declaration in your spring context. (See Section 3.12.2 in the spring docs here.