Configuración de pooling en Spring

Si bien las capacidades que nos ofrece EJB para pools de instancias son muy utilizadas, de ningún modo es la única forma de llevar a cabo esta tarea. Apache Commons Pool por ejemplo, es una biblioteca muy utilizada para el mismo fin.
Si queremos utilizar Spring Framework para abstraer su utilización, solo tenemos que agregar los beans necesarios a nuestro archivo de configuración para ofrecer capacidades de pooling a cualquier objeto.

Primero definimos el bean como cualquier otro, teniendo en cuenta que el nombre que le pongamos no será el nombre final a utilizar, y que no sea singleton:

<bean id="myServiceTarget" class="com.xyz.ServiceImpl" singleton="false">

  <property name="..."><value>...</value></property>

  <property name="..."><ref bean="..."/></property>

<bean>

Acto seguido definimos nuestro pool, mediante la utilización de CommonsPoolTargetSource, especificando nuestro bean target, y la cantidad de instancias permitidas:

<bean id="myServicePoolTargetSource"

  class="org.springframework.aop.target.CommonsPoolTargetSource">

  <property name="targetBeanName"><value>myServiceTarget</value></property>

  <property name="maxSize"><value>25</value></property>

</bean>

Finalmente definimos nuestro bean final, mediante un proxy AOP:

<bean id="myService"

      class="org.springframework.aop.framework.ProxyFactoryBean">

  <property name="proxyInterfaces">

    <value>com.xyz.Service</value>

  </property>

  <property name="targetSource">

    <ref local="myServicePoolTargetSource"/>

  </property>

</bean>

Ahora podemos utilizar el bean myService y ante cada llamada a uno de sus métodos, Spring obtendrá una instancia del pool, ejecutará el codigo de nuestro método y devolverá la instancia al pool, todo mediante "AOP magic". ¿Sencillo, no?

Planificación de Iteraciones

Estoy en difícil tarea de convencer al "executive management" de la necesidad de una herramienta de planificación que soporte desarrollo iterativo, y a la vez recomendar la que se adapte a nuestras necesidades. Hasta ahora he visto VersionOne, Rally y xPlanner, sin que ninguna abarque todo el espectro del desarrollo.

VersionOne es una herramienta que soporta "solo" el planning. Tiene Proyectos, Releases, Iteraciones, Stories, Tasks y Tests. Por supuesto con el correspondiente set de herramients de análisis (muy completo por cierto) donde se incluye el Velocity.

Rally además tiene UseCases y Actors, posiblemente un remanente del Proceso Unificado, y Defects. Y con mucha documentación.

xPlanner es el único OpenSource y quizás el mas modesto. No tiene Releases ni Tests.

En cuanto a planning de las iteraciones y seguimiento de las horas realizadas en cada Story/Task, no tengo dudas que cualquiera serviría. Quizás el mas "ágil" para XP sería VersionOne, y para ProcesoUnificado iría bien Rally.

Pero a todos les falta, según mis necesidades, una forma de llevar los requerimientos en forma mas detallada, WorkProducts (a la Proceso Unificado) personalizados, y un sistema de seguimiento de defectos mas sofisticado, sin llegar a ser JIRA, pero casi.

Method Injection en Spring

Lo que se hace hasta ahora para obtener un bean prototipo (no singleton) en Spring, es implementar la interface BeanFactoryAware y luego utilizar getBean("NombreDelBean") del contenedor para obtener la instancia.
Esto no es muy deseable, ya que nos "pega" demasiado a Spring. Nuestros beans "conocen" a Spring.

La nueva posibilidad de Spring 1.1, Method Injection le permite al contenedor sobreescribir un método abtracto o concreto de los beans que administra, para devolver el resultado de una búsqueda de otro bean del contenedor.

Tomemos el ejemplo de la documentación de Spring. Si tenemos un clase cliente conteniendo el método a ser inyectado de esta forma:

protected abstract SingleShotHelper createSingleShotHelper();

podemos escribir el siguiente lookup-method tag en la configuración de Spring para sobreescribir su comportamiento y que nos devuelva la instancia que necesitemos:

<bean id="singleShotHelper" class="..." singleton="false"/>



<bean id="myBean" class="...">

  <lookup-method name="createSingleShotHelper" bean="singleShotHelper"/>

  <property>

    ...

  </property>

</bean>

Asi, el bean myBean puede ahora llamar a su propio método createSingleShotHelper y obtener una nueva instancia del bean singleShotHelper.

Con esto desacoplan mas nuestras clases de Spring y se simplifican aún mas las pruebas unitarias.

Treebolic

Treebolic es un applet Java cuyo propósito es crear una representación hiperbólica de datos jerárquicos.

Los datos se pueden obtener de un fichero XML (local o via http/ftp) o directamente de una base de datos.

El resultado de un XML como este:

<treebolic>

  <tree>

    <nodes>

      <node id="root" backcolor="0033cc" forecolor="ffffff">

        <label>Raiz</label>

        <node id="X6ea8a92149d7615a">

          <label>Nodo A</label>

          <img src="bball.gif"/>

        </node>

        <node id="Xbcada8f2a9b0467d">

          <label>Nodo B</label>

          <img src="rball.gif"/>

        </node>

        <node id="X2a4990a7fa4e9d1c" backcolor="ffffff">

          <label>Nodo C</label>

          <img src="rball.gif"/>

          <node id="Xf439a01d7dd25f00">

            <label>Nodo C-0</label>

          </node>

          <node id="X61cda71acafdf5c6">

            <label>Nodo C-1</label>

          </node>

          <node id="Xf9bb23281bbd8fbe" backcolor="009900" forecolor="ffffff">

            <label>Nodo C-2</label>

            <node id="Xe566c4465c94c922">

              <label>C-2-0</label>

            </node>

            <node id="Xc2ec6980243315a0">

              <label>C-2-1</label>

            </node>

            <node id="X364fd28b294610a2">

              <label>C-2-2</label>

              <img src="item.gif"/>

            </node>

          </node>

          <node id="X67babf94b0a57d0a">

            <label>Nodo C-3</label>

          </node>

          <node id="Xb65e58ea11f5a30d">

            <label>Nodo C-4</label>

          </node>

          <node id="Xc196ad20dff21769">

            <label>Nodo C-5</label>

          </node>

        </node>

      </node>

    </nodes>

  </tree>

</treebolic>

es el siguiente:



Lo interesante de esta vista es que es dinámica, se puede navegar de un nodo a otro y el applet mueve el nodo seleccionado al centro de la pantalla, mostrando los nodos padres/hijos en forma circular a su alrededor, cada vez mas pequeños a medida que nos alejamos del centro.

Cada nodo debe tener su id y el texto a mostrar como mínimos requerimientos, pero también se pueden asociar una url, una imagen y un color.
Siendo una herramienta de visualización de datos, es muy útil el poder especificar el color/imagen de cada nodo, ya que nos permite llamar la atención sobre alguna particularidad del mismo. En el ejemplo anterior, los nodos B y C tienen una imagen en rojo y el nodo C-2 es de color verde.

Y los datos no tienen por que estar en un solo XML, ni cargarse todos a la vez, podemos decirle a un nodo que "monte" otro xml al inicio, o cuando hacemos doble click sobre el.

Aquí podemos ver otro ejemplo:


También se pueden seleccionar los datos desde una base de datos, directamente o mediante un servlet que convierta el resultado de una query en xml y lo envíe al applet.
La query de los nodos para obtener los datos míninos es la siguiente:

SELECT id_node, 

       path, 

       descripcion AS label 

  FROM Nodos;

con este resultado:

id_node	path	label
animal	[NULL]	animal
vertebrate	/animal	vertebrate
mammal	/animal/vertebrate	mammal
eutherian	/animal/vertebrate/mammal	eutherian
carnivorous	/animal/vertebrate/mammal/eutherian	carnivorous
cat	/animal/vertebrate/mammal/eutherian/carnivorous	cat
tiger	/animal/vertebrate/mammal/eutherian/carnivorous	tiger

Alguien me dijo que es un chupete para ejecutivos, y aunque no está muy errado es una excelente herramienta de visualización rápida de datos.
Si comparamos por ejemplo esta forma de ver los datos para un cuadro de mando con un listado de dos páginas con números indicadores de "como va la empresa", se gana en claridad y rapidez para ver cualquier alarma que especifiquemos.

Tiger - Enhanced for loop

¿Quien no ha tenido que iterar en una colección para hacer algo con los elementos que la componen? Teniendo una colección c de Strings, la forma de hacerlo hoy dia podría ser esta:

for (Iterator i = c.iterator(); i.hasNext(); ) {
    String s = (String) i.next();
    ...
}

O incluso esta con los nuevos generics, que permiten ahorrarnos el cast:

for (Iterator<String> i = c.iterator(); i.hasNext(); ) {
  String s = i.next();
  ...
}

Pero Java 5 provee ahora una manera mas simple de hacerlo, a la foreach:

for (String s : c) {
    ...
}

Lo interesante de esto también, es que quien se encarga de la nueva syntaxis es el compilador, lo cual hace que sea transparente para la VM.