JBoss Application Server 7, con soporte para Java EE 6

La semana pasada Red Hat anunció JBoss Application Server 7. Entre las novedades se encuentra soporte para el web profile de Java EE 6, un tiempo de arranque considerablemente inferior (hasta 10 veces más rápido que la versión anterior), un menor uso de memoria, un diseño más modular que consigue ocultar detalles de implementación y mostrar sólo el API (empleando trucos con cargadores de clases) y una nueva consola de administración simplificada y más intuitiva.

A pesar de algunos comentarios por parte de la compañía donde afirman que su servidor tiene soporte para Java EE 6 y que están "leading the pack. again.", esta vez han llegado ligeramente por detrás de WebSphere V8 (y también detrás del servidor de JEUS 7 de Tmaxsoft), y encima ellos sólo implementan el Web profile y no Java EE al completo. Por una vez el gigante azul va por delante de ellos.

¿Cuanto se empleais JBoss por aquí?

 

Artículo: Generar Temas de Colores en ZK por Manuel Martínez

Manuel Martínez desde Colombia nos ha mandado este Artículo sobre personalización del framework de componente Ajax ZK. En este artículo tipo How-To, aprenderás a generar temas de colores para tu interfaz gráfica y cambiarlos de forma dinámica en runtime.

Gracias  a Manuel por este documento.

Selenium 2.0

Este fin de semana se ha liberado la versión 2.0 de Selenium, el framework para testeo de aplicaciones web. En esta nueva versión, además de los esperados bug fixes y soporte para navegadores más modernos (como Firefox 5 y IE 9), la gran novedad es WebDriver APIs para Python, Ruby, Java y C#. WebDriver permite definir test para una aplicación web empleando lenguajes de programación (alguno de los cuatro mencionados anteriormente) con los que el programador se siente cómodo.

Para que os hagáis una idea, os dejo aquí un ejemplo sacado de su documentación para Java:

 
       //Crear una instancia de  Firefox 
        WebDriver driver = new FirefoxDriver();
        //y la usamos para visitar Google
        driver.get("http://www.google.com");
        //localizamos la caja de texto de la búsqueda
        WebElement element = driver.findElement(By.name("q"));
        //e introducimos en la caja el texto para la búsqueda
        element.sendKeys("Cheese!");
        //enviamos la búsqueda
        element.submit();
        // Check the title of the page
        System.out.println("Page title is: " + driver.getTitle());
        
        // esperamos a que Google genere dinámicamente con JavaScript la respuesta.
        //haciendo un timeout despues de 10 segundos
        (new WebDriverWait(driver, 10)).until(new ExpectedCondition() {
            public Boolean apply(WebDriver d) {
                return d.getTitle().startsWith("cheese!");
            }
        });
        //El titulo de la pagina deberia ser: "cheese! - Google Search"
        System.out.println("Page title is: " + driver.getTitle());
        
        //liberamos los recursos del navegador
        driver.quit();
   

Además, Selenium 2.0 tiene soporte para realizar test distribuidos empleando Selenium Grid, que puede emplear tanto el API original de Selenium como WebDriver. En estos momentos Selenium IDE todavía no soporta todas las nuevas características de la versión 2.0, pero la semana que viene deberían sacar la versión 1.1.0 de Selenium IDE con soporte para ellas. 

¿Cuantos por aquí empleais Selenium? 

Rod Johnson aclara su punto de vista sobre OSGi

Hace un par de semanas Rod Johnson hizo unas declaraciones sobre OSGi que resultaron bastante polémicas. Según él, OSGi sencillamente no puede ser hecho lo suficientemente sencillo y productivo para ser consistente con los valores del framework Spring. Para él, con el tiempo ha quedado claro que esta tecnología es una tecnología para nichos muy acotados, pero que nunca va a ser mainstream. 

Después de todo el revuelo formado, Rod ha sentido que necesita aclarar su posición respecto a esta tecnología. Primero, quiere dejar claro que estas declaraciones son sólo su opinión, y no necesariamente la de SpringSource o VMware.

Segundo, aclara que su compañía ha hecho una inversión considerable en OSGi a través de dm Server. Que a pesar de que han donado esta tecnología a Eclipse continúan participando en ella, siguen teniendo beneficios económicos de ella, tienen clientes que la usan y seguirán manteniendola.

Pero que las lecciones que ha aprendido acerca de OSGi son:

• OSGi es una solución genial para aplicaciones que tienen requerimientos de modularidad muy elevados.
• La aplicación típica empresarial no tiene estos requerimientos.
• A pesar de los esfuerzos de su compañía para reducir la complejidad de OSGi para que pudiese ser empleado en aplicaciones típicas empresariales, no consiguieron llevar el proyecto a buen puerto. Para ellos no estaba claro si iban a poder conseguir este objetivo, y decidieron abandonar el intento.

Quizás sea sólo yo, pero esto es básicamente lo que yo ya había entendido la primera vez. Nadie puede negar que OSGI es una tecnología genial (véase Eclipse o Glasfish). Pero es demasiado compleja para la mayor parte de las aplicaciones que se desarrollan en el ambiente empresarial. En general, tiende a ser una tecnología más de infraestructura/framework de bajo nivel que una tecnología que tenga sentido usar a nivel donde trabajamos la mayor parte de los programadores Java.

¿Cuál es vuestra opinión al sobre OSGi?

 

Apache Lucene/Apache Solr 3.3

La fundación Apache ha anunciado Lucene y Solr 3.3. Entre las novedades de esta versión de Lucene se encuentra funcionalidad de autocompletado, soporte para hacer un merge de resultados que provienen de múltiples "shards" y diversas funcionalidades relacionadas con la gestión de los índices. 

Solr 3.3 incluye diversas mejoras de rendimiento, especialmente en lo que a consumo de memoria RAM durante el chequeo de sintaxis se refiere, además de la mejoras relacionadas con Lucene 3.3.