En este ejemplo nos vamos a concentrar en la configuración del SessionFactory de Hibernate y las diferentes alternativas que nos ofrece el sistema de abstracción de recursos para simplificar la configuración y mantener distintas configuraciones.
A continuación veamos una configuración básica del sessionFactory de Spring para Hibernate con conexión a Oracle.
<bean id=“sessionFactory”
class=“org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
<property name=“dataSource”>
<ref bean=“dataSource” />
</property>
<property name=“hibernateProperties”>
<props>
<prop key=“hibernate.dialect”> org.hibernate.dialect.Oracle9Dialect
</prop>
<prop key=“hibernate.show_sql”> false</prop>
<prop key=“hibernate.cglib.use_reflection_optimizer”> true
</prop>
</props>
</property>
<property name=“mappingResources”>
<list> <value>sadiel/rrhhsas/model/adm/usu/objnegocio/Perfil.hbm.xml</value> <value>sadiel/rrhhsas/model/adm/usu/objnegocio/Usuario.hbm.xml</value> <value>sadiel/rrhhsas/model/adm/usu/objnegocio/UsuarioPerfil.hbm.xml</value>
</list>
</property>
</bean>
El primer problema que podemos ver es que la lista de mappingResources va a crecer continuamente y se hará muy extensa. Cualquiera ha trabajado en un proyecto con 100 tablas o más.
Afortunadamente LocalSessionFactoryBean tiene otra propiedades de tipo Resource[] que no va a permitir solucionar este problema. Y la configuración quedaría de este modo.
<property name=“mappingLocations”>
<!– Cargamos todos los ficheros hibernate que haya en el classpath dentro del paquete –>
<value>classpath:sadiel/**/*.hbm.xml</value>
</property>
Quizás más sutil, pero tampoco parece coherente tener una configuración compleja como la configuración de hibernate, dentro de la configuración de la aplicación. Sobretodo pensando que podemos tener distintas configuraciones para entornos diferentes, o para clientes diferentes.
En este caso LocalSessionFactoryBean no nos puede ayudar directamente ya que no tiene una propiedad de tipo Resource para configurar las propiedades de hibernate. Sin embargo si que podemos hacer referencia a otro bean que contenga estas propiedades.
<bean id=“sessionFactory”
class=“org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
<property name=“dataSource”>
<ref bean=“dataSource” />
</property>
<property name=“hibernateProperties”>
<ref bean=“hibernateProperties” />
</property>
<property name=“mappingLocations”>
<value>classpath:sadiel/**/*.hbm.xml</value>
</property>
</bean>
<bean id=“hibernateProperties”
class=“sadiel.rrhhsas.model.comun.util.ResourcePropertiesUtil”>
<property name=“propertiesLocations”>
<value>classpath:hibernate.properties</value>
</property>
</bean>
De esta manera volvemos a usar el tradicional archivo de configuración hibernate.properties.
La implementación de ResourcePropertiesUtil es muy sencilla, pero la incluyo por completitud.
package sadiel.rrhhsas.model.comun.util;
public class ResourcePropertiesUtil extends Properties {
private Resource[] propertiesLocations;
public void setPropertiesLocations(Resource[] propertiesLocations) throws IOException {
this.propertiesLocations = propertiesLocations;
for (Resource resource : propertiesLocations) {
super.load(resource.getInputStream());
}
}
}
Suponiendo que tenemos que mantener diversas configuraciones, podríamos definir el bean con diferentes propiedades y obtener una de ellas según otro parámetro de configuración.
Existen otras propiedades que pueden aprovechar esta aproximación de la configuración. Trabajando con Spring 1.1 sólo era posible definir la caché de segundo nivel de Hibernate en cada uno de los fichero hbm. Pero desde la versión de Spring 1.2 es posible informar la caché de clases en la propiedad entityCacheStrategies y la caché de colecciones en la propiedad collectionCacheStrategies, ambas de tipo Properties.
Dejo el resto a vuestra imaginación.
Referencias
http://www.springframework.org/docs/reference/resources.html
