Nuevo namespace en Spring 2.0

read this in english

Una forma mas bien rara de configurar los beans de Spring parece ser la que Rod Johnson nos recuerda en una entrada de su blog.
Básicamente se puede utilizar un nuevo namespace "p" para utilizar los atributos de un XML como propiedades de los beans.
Lo que normalmente haríamos así:

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans 
       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="empleado" class="package.Empleado">
      <property name="empresa" ref="empresa" />
      <property name="horasSemanales" value="35" />
    </bean>

    <bean id="empresa" class="package.Empresa" />

</beans>

Lo podríamos hacer así:

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:p="http://www.springframework.org/schema/p"
   xsi:schemaLocation="http://www.springframework.org/schema/beans 
       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="empleado" class="package.Empleado"
        p:direccion-ref="empresa"
        p:horasSemanales="35" />

    <bean id="empresa" class="package.Empresa" />

</beans>

Un pequeño cambio que podría hacer nuestros XMLs mas compactos, aunque no se si mas legibles.

Mas ejemplos aquí.

Compartir URLs

read this in english

Aprovechando que es Lunes (quiero quejarme de algo) y que ya lo he leído por ahí, quiero apoyar una idea:
Sería hora que alguien pusiera orden al infierno de compartir URLs. Lo que aparece normalmente en los artículos () no es sostenible. Que cada web para compartir vínculos tengo su propia forma de hacerlo es muy del siglo pasado. No digo de llegar al extremo de hacer una JSR para ello, pero algún orden no vendría mal.

Java web frameworks - Cuál elegir?

read this in english

Si hay algo imposible en estos días (y desde hace tiempo) es elegir un framework web en Java. Es mas cuestión de gusto que de tecnología. Y eso molesta. Hace que la competencia (léase .NET) sean mucho mas fáciles de adoptar. Cuáles de ellos hay que seguir día a día para ver como avanzan? En mi opinión:

• Shale Basado en JavaServer Faces.
• Wicket Modelado web... en java.
• Stripes MVC clásico, pero con casi cero configuración.
• Seam Basado en EJB 3.0 y un poco pegado a productos JBOSS.

Update: Con el nuevo Seam 1.1 se pueden utilizar POJOs fuera de un servidor EJB 5.0. Incluso con Tomcat.

Tecnologías con las que me gustaría trabajar (I)

read this in english

Una de las tecnologías con las que me gustaría hacer algo productivo (léase: encontrar un cliente que me pague por hacer una aplicación) es JCR (Java Content Repository).
La JSR-170 especifica la forma en la que deberíamos comunicarnos con los repositorios de contenido. Los repositorios de contenido o "Content Management Systems" (CMS) como Documentum o Vignette nos permiten guardar información binaria o de texto sin tener que preocuparnos por dónde se hace, es decir si se utiliza una base de datos relacional o ficheros XML. Pero cada vendedor tiene su propio producto y su propia forma de acceder a la información, por lo que la JSR-170 trata de resolver el problema de la estandarización.
En el mundo open source, Apache JackRabbit es la implementación de referencia.
La información es organizada en nodos de un árbol, teniendo cada nodo "atributos" o "propiedades" donde guardar los datos. Por ejemplo, para guardar información podríamos (ejemplo tomado de aquí):

    Session session = JackrabbitPlugin.getSession();
                Node rootNode = session.getRootNode();
    Node blogEntry = rootNode.addNode("blogEntry");
    blogEntry.addMixin("mix:versionable");
    blogEntry.setProperty(PROP_TITLE, blogEntryDTO.getTitle());
    blogEntry.setProperty(PROP_BLOGCONTENT, blogEntryDTO.getBlogContent());
    blogEntry.setProperty(PROP_CREATIONTIME, blogEntryDTO.getCreationTime());
    blogEntry.setProperty(PROP_BLOGAUTHOR, blogEntryDTO.getUserName());
    session.save();

Con lo que lograríamos crear un nodo, hacerlo versionable (uno de los servicios de la JSR), llenarlo con nuestra información y guardarlo.

Nunca se sabe, quizás en un futuro próximo convenza a alguien para utilizar Jackrabbit. Deséenme suerte!

Pico y Spring

read this in english

PicoContainer, alguien se acuerda de él? Es un contenedor de componentes que utiliza inyección de dependencias. Pero fue avasallado por el huracán Spring, aunque sigue teniendo sus adeptos incondicionales.
Y tan incondicionales que a veces (como otras tecnologías) se utiliza simplemente porque "es lo que sé", dejando de lado las "que no se" pero nos da mucha mas funcionalidad a nuestra arquitectura.
Pero como nada en esta vida es permanente (ni siquiera si utilizamos hibernate), y todo llega (incluso Java como open source), mi amigo Ale pudo finalmente "refactorizar" una aplicación para cambiar Pico por... Spring.