Diferencia entre revisiones de «Inicializacion Lazy De Spring Para Tests»

De Dos Ideas.
Saltar a: navegación, buscar
Línea 1: Línea 1:
[[Spring Framework]] provee un mecanismo por el cual se le puede indicar que un bean sea consturído lo más tardíamente posbile.
+
[[Spring Framework]] provee un mecanismo por el cual se le puede indicar que un bean sea consturído lo más tardíamente posbile.  
  
De esta manera el bean no se instanciará hasta que no se necesite en el código en tiempo de ejecución en forma directa o porque es la dependencia de otro bean que es necesario.
+
De esta manera el bean no se instanciará hasta que no se necesite en el código en tiempo de ejecución en forma directa o porque es la dependencia de otro bean que es necesario.  
  
Se puede utilizar a nivel de bean:
+
Se puede utilizar a nivel de bean: <code xml="xml"><bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true"/></code>  
<code xml><bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true"/></code>
 
  
o a nivel del contenedor
+
o a nivel del contenedor <code xml="xml">
<code xml>
 
 
<beans default-lazy-init="true">
 
<beans default-lazy-init="true">
 
   ...
 
   ...
 
</beans>
 
</beans>
</code>
+
</code>  
  
Esto es muy útil durante los tests de componentes ya que nos permite inicializar e involucrar en el test solamente los beans relacionados.
+
Esto es muy útil durante los tests de componentes ya que nos permite inicializar e involucrar en el test solamente los beans relacionados.  
  
El problema que surge es que es conveniente utilizar los mismos archivos de configuración que irán a producción. Así estaremos testeando que la configuración de Spring sea correcta.
+
Durante los tests de componentes es conveniente utilizar los mismos archivos de configuración que se utilizarán en producción. Así se estará comprobando que la configuración de Spring es correcta.  
  
Imaginemos los siguientes archivos de configuración:
+
El problema que surge es que si se quiere indicar en la configuración que la incialización sea lazy se estará duplicando los archivos de configuración perdiendo esta posibilidad.
  
app-business.xml
+
Imaginemos los siguientes archivos de configuración:
<code xml>
+
 
 +
app-business.xml <code xml="xml">
 
<beans>
 
<beans>
 
     ...
 
     ...
 
     <bean id="UnBo" ...>
 
     <bean id="UnBo" ...>
    ...
 
    <bean id="OtroBo" ...>
 
 
     ...
 
     ...
 
</beans>
 
</beans>
</code>
+
</code>  
  
app-dao.xml
+
app-dao.xml <code xml="xml">
<code xml>
 
 
<beans>
 
<beans>
 
     ...
 
     ...
 
     <bean id="UnDao" ...>
 
     <bean id="UnDao" ...>
    ...
 
    <bean id="OtroDao" ...>
 
 
     ...
 
     ...
 
</beans>
 
</beans>
</code>
+
</code>  
  
app-jms.xml
+
app-jms.xml <code xml="xml">
<code xml>
 
 
<beans>
 
<beans>
 
     ...
 
     ...
 
     <bean id="UnJmsTemplate" ...>
 
     <bean id="UnJmsTemplate" ...>
    ...
 
    <bean id="OtroJmsTemplate" ...>
 
 
     ...
 
     ...
 
</beans>
 
</beans>
</code>
+
</code>  
  
Un test [[JUnit]] de componentes comenzaría con algo así:
+
Un test [[JUnit]] de componentes comenzaría con algo así:  
  
<code java>
+
<code java="java">
 
@ContextConfiguration(locations =  
 
@ContextConfiguration(locations =  
 
     "classpath:app-business.xml",
 
     "classpath:app-business.xml",
Línea 63: Línea 54:
 
     ...
 
     ...
 
}
 
}
</code>
+
</code>  
  
Si queremos que la inicialización sea lazy, cada uno de los archivos de configuración debería comenzar con:
+
Si queremos que la inicialización sea lazy, cada uno de los archivos de configuración debería comenzar con: <code xml="xml">
<code xml>
 
 
<beans default-lazy-init=true>
 
<beans default-lazy-init=true>
</code>
+
</code>  
  
Esto implica que tengamos que tener archivos alternativos para los tests:
+
Esto implica que tengamos que tener archivos alternativos para los tests: <code java="java">
<code java>
 
 
@ContextConfiguration(locations =  
 
@ContextConfiguration(locations =  
 
     "classpath:app-business-componente-test.xml",
 
     "classpath:app-business-componente-test.xml",
Línea 80: Línea 69:
 
     ...
 
     ...
 
}
 
}
</code>
+
</code>  
  
Una solución que suponemos que debería funcionar es importar los tres archivos en otro y hacer a este lazy:
+
=== Una solución que no funciona ===
  
 +
Es muy común intentar solucionar el problema de tener que duplicar los archivos de configuración importando los tres archivos en otro y hacer a este lazy:
  
<code xml>
+
<br> app-spring-config-componente-test.xml <code xml="xml">
 
<beans default-lazy-init="true">
 
<beans default-lazy-init="true">
 
     <import resource="app-business.xml" />
 
     <import resource="app-business.xml" />
Línea 91: Línea 81:
 
     <import resource="app-jms.xml" />
 
     <import resource="app-jms.xml" />
 
</beans>
 
</beans>
</code>
+
</code>  
  
Y después lo incluímos como un sólo archivo:
+
Y después lo incluímos como un sólo archivo:  
  
<code java>
+
<code java="java">
  
 
@ContextConfiguration(locations =  
 
@ContextConfiguration(locations =  
Línea 103: Línea 93:
 
     ...
 
     ...
 
}
 
}
</code>
+
</code>  
 +
 
 +
Lo que no funciona es que la propiedad default-lazy-init no se propaga por las configuraciones importadas (Verificar si esto sigue siendo así en versiones más nuevas de Spring).
  
El problema es que la propiedad default-lazy-init no se propaga por las configuraciones importadas (Verificar si esto sigue siendo así en versiones más nuevas de Spring).
+
=== Solución  ===
  
===Posible Solución===
+
Una alternativa para hacer la inicialización lazy durante los tests sin duplicar los archivos de configuración es crear un ContextLoader propio y especificarlo en la anotación @ContextConfiguration.  
Una posible solución para esto es crear un ContextLoader propio y especificarlo en la anotación @ContextConfiguration.
 
  
El ContextLoader utilizará un DefinitionDocumentReader que le seteará a cualquier definición que lea, el atributo DEFAULT_LAZY_INIT_ATTRIBUTE como true.
+
El ContextLoader utilizará un DefinitionDocumentReader que le seteará a cualquier definición que lea, el atributo DEFAULT_LAZY_INIT_ATTRIBUTE como true.  
  
<code java>
+
<code java="java">
 
package com.tm.cma.web.base;
 
package com.tm.cma.web.base;
  
Línea 147: Línea 138:
 
     }
 
     }
  
</code>
+
</code>  
  
Y así quedaría el test en cuestión:
+
Y así quedaría el test en cuestión: <code java="java">
<code java>
 
  
 
@ContextConfiguration(
 
@ContextConfiguration(
Línea 159: Línea 149:
 
     ...
 
     ...
 
}
 
}
</code>
+
</code>  
  
[[Category: Spring Framework]]
+
[[Category:Spring_Framework]] [[Category:JUnit]]
[[Category: JUnit]]
 

Revisión del 13:05 7 oct 2009

Spring Framework provee un mecanismo por el cual se le puede indicar que un bean sea consturído lo más tardíamente posbile.

De esta manera el bean no se instanciará hasta que no se necesite en el código en tiempo de ejecución en forma directa o porque es la dependencia de otro bean que es necesario.

Se puede utilizar a nivel de bean: <bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true"/>

o a nivel del contenedor <beans default-lazy-init="true">

  ...

</beans>

Esto es muy útil durante los tests de componentes ya que nos permite inicializar e involucrar en el test solamente los beans relacionados.

Durante los tests de componentes es conveniente utilizar los mismos archivos de configuración que se utilizarán en producción. Así se estará comprobando que la configuración de Spring es correcta.

El problema que surge es que si se quiere indicar en la configuración que la incialización sea lazy se estará duplicando los archivos de configuración perdiendo esta posibilidad.

Imaginemos los siguientes archivos de configuración:

app-business.xml <beans>

   ...
   <bean id="UnBo" ...>
   ...

</beans>

app-dao.xml <beans>

   ...
   <bean id="UnDao" ...>
   ...

</beans>

app-jms.xml <beans>

   ...
   <bean id="UnJmsTemplate" ...>
   ...

</beans>

Un test JUnit de componentes comenzaría con algo así:

@ContextConfiguration(locations =

   "classpath:app-business.xml",
   "classpath:dao-business.xml",
   "classpath:jms-business.xml"
   )

public class BlahComponenteTest extends AbstractJUnit4SpringContextTests {

   ...

}

Si queremos que la inicialización sea lazy, cada uno de los archivos de configuración debería comenzar con: <beans default-lazy-init=true>

Esto implica que tengamos que tener archivos alternativos para los tests: @ContextConfiguration(locations =

   "classpath:app-business-componente-test.xml",
   "classpath:dao-business-componente-test.xml",
   "classpath:jms-business-componente-test.xml"
   )

public class BlahComponenteTest extends AbstractJUnit4SpringContextTests {

   ...

}

Una solución que no funciona

Es muy común intentar solucionar el problema de tener que duplicar los archivos de configuración importando los tres archivos en otro y hacer a este lazy:


app-spring-config-componente-test.xml <beans default-lazy-init="true">

   <import resource="app-business.xml" />
   <import resource="app-dao.xml" />
   <import resource="app-jms.xml" />

</beans>

Y después lo incluímos como un sólo archivo:

@ContextConfiguration(locations =

   "classpath:app-spring-config-componente-test.xml"
   )

public class BlahComponenteTest extends AbstractJUnit4SpringContextTests {

   ...

}

Lo que no funciona es que la propiedad default-lazy-init no se propaga por las configuraciones importadas (Verificar si esto sigue siendo así en versiones más nuevas de Spring).

Solución

Una alternativa para hacer la inicialización lazy durante los tests sin duplicar los archivos de configuración es crear un ContextLoader propio y especificarlo en la anotación @ContextConfiguration.

El ContextLoader utilizará un DefinitionDocumentReader que le seteará a cualquier definición que lea, el atributo DEFAULT_LAZY_INIT_ATTRIBUTE como true.

package com.tm.cma.web.base;

import org.springframework.beans.factory.support.BeanDefinitionReader; import org.springframework.beans.factory.xml.BeanDefinitionParserDelegate; import org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader; import org.springframework.beans.factory.xml.XmlBeanDefinitionReader; import org.springframework.beans.factory.xml.XmlReaderContext; import org.springframework.context.support.GenericApplicationContext; import org.springframework.test.context.support.GenericXmlContextLoader; import org.w3c.dom.Element;

public class LazyContextLoader extends GenericXmlContextLoader {

   protected BeanDefinitionReader 
           createBeanDefinitionReader(GenericApplicationContext context) {
       XmlBeanDefinitionReader beanDefinitionReader = 
           new XmlBeanDefinitionReader(context);
       beanDefinitionReader.setDocumentReaderClass(LazyBeanDocumentReader.class);
       return beanDefinitionReader;
   }

}

class LazyBeanDocumentReader extends DefaultBeanDefinitionDocumentReader {

   protected BeanDefinitionParserDelegate 
           createHelper(XmlReaderContext readerContext, Element root) {
       root.setAttribute(
           BeanDefinitionParserDelegate.DEFAULT_LAZY_INIT_ATTRIBUTE,
           "true"
           );
       return super.createHelper(readerContext, root);
   }

Y así quedaría el test en cuestión:

@ContextConfiguration(

       loader = "LazyContextLoader.class"
       locations = "classpath:app-spring-config-componente-test.xml"
   )

public class BlahComponenteTest extends AbstractJUnit4SpringContextTests {

   ...

}