Como es justo el tema con el que estoy, antes de que se me olvide lo pongo aquí. Son solo unas pequeñas notas que puede que no se tengan claras.

En un post anterior explique las diferentes opciones del compilador de GWT, pero a la hora de hacer el build tenia algunas dudas, os pondré los resultados de las pruebas.

• En ningun momento es necesario incluir el código fuente en el build para producción

• Aunque si debe estar accesible el código fuente para su compilación (es obvio), yo en este caso suelo meter en diferentes jars los fuentes y copilados de los diferentes módulos, para luego incluirlo en el classpath del proyecto principal.

La verdad es que cuando pensé en escribir un post, pensé que tendría mas chicha, pero me ha resultado todo un reto montar un build con diferentes módulos y proyectos, aunque ahora ya terminado parece una tontería.

Estos días ando un poco liado con el desarrollo de una aplicación en GWT. Que con esta ultima versión, la 2.0, se puede decir que han dado un paso de gigante.
En esta ocasión voy a hablar de su compilador para la puesta en producción y los parámetros que tiene.

Antes de nada explicar un poco como funciona, GWT coge y compila a javascript nuestro codigo creando diferentes versiones en archivos diferentes. Si nos fijamos en lo que genera veremos que hay una serie de archivos con extensiones html, rpc, png. Los png son los bundle, donde mete todas las imágenes de la aplicación en una sola, descargándola de golpe y luego muestra la parte que interese. Los archivos rpc son los encargados de las llamadas a los servicios y los html son donde esta toda la chicha.

Veremos que son del estilos LKH45KH6KLJH4356H3456HLKH45.cache.html, cada archivo represente a un idioma/navegador. Así que si tenemos 2 idiomas y 5 navegadores, tendremos 10 archivos o permutaciones como ellos los llaman.

Cada compilación lleva su tiempo, y en las tareas ant que utilicemos podremos introducir algunos parámetros que agilicen esta compilación.

Si tenemos varios módulos, es interesante que los compilemos en una misma tarea, indicando a cada llamada java que sea un fork, para que se compile en paralelo.

Y hacemos uso de unos de los parámetros mas interesantes, el localworkers, esto representa a un hilo que compila una permutación, así que si ponemos mas, compilaría paralelamente las permutaciones, aquí que cada uno hagas sus pruebas. Yo tengo 4 núcleos y poniéndolo en 4 se me reduce a la mitad el tiempo necesario para compilar.
Os dejo una muestra en ant.

<target name="gwtc" depends="javac" description="GWT compile to JavaScript">
<!-- Compilacion modulo vo -->
<java failonerror="false" fork="true" classname="com.google.gwt.dev.Compiler">
<classpath>
<pathelement location="modules"/>
<path refid="project.class.path"/>
</classpath>
<!-- add jvmarg -Xss16M or similar if you see a StackOverflowError -->
<jvmarg value="-Xmx256M"/>
<!-- Additional arguments like -style PRETTY or -logLevel DEBUG -->
<arg value="com.orion.apps.cuentas.ValueObject"/>
<arg line="-war ${build.dir}"/>
<arg line="-style DETAILED"/>
<arg line="-localWorkers 4"/>
</java>

<!-- Compilacion modulo cuentas-->
<java failonerror="false" fork="true" classname="com.google.gwt.dev.Compiler">
<classpath>
<pathelement location="view/main/java"/>
<pathelement location="view/main/resources"/>
<pathelement location="rpc/main/java"/>
<pathelement location="modules"/>
<path refid="project.class.path"/>
</classpath>
<!-- add jvmarg -Xss16M or similar if you see a StackOverflowError -->
<jvmarg value="-Xmx256M"/>
<!-- Additional arguments like -style PRETTY or -logLevel DEBUG -->
<arg line="-war ${build.dir}"/>
<arg line="-style DETAILED"/>
<arg line="-localWorkers 4"/>
<arg value="com.orion.apps.cuentas.web.CuentasWeb"/>
</java>
</target>

PD: Si se quiere ir mas rápido, se puede eliminar idiomas del archivo de configuración gwt.xml

Un año mas el curso de especialista en JEE ha organizado una jornada de charlas sobre java y software libre. Aunque el año anterior no hubo, este año han vuelto con un buen abanico de ponentes muy buenos.

En su pagina web, podéis ver con mas detalle quienes han venido. Un resumen de las que hubo:

• GWT con Emilio bravo. Amigo y compañero de proyectos, hablo de una tecnología que ya llevo tiempo utilizando y son un fan convencido.

• Agilidad con Martin Perez. Otro amigo el cual tuve el privilegio de conocer con su anterior proyecto de Jlibrary. Como siempre magistral, se nota que no es su primera ponencia. Además hablo de un tema muy interesante y que además me cojea bastante. Así que con las aclaraciones que ha hecho creo que me voy a poner en serio a utilizar el diseño basado en pruebas y las metodologías ágiles.Además comento varios aspectos del mundo empresarial a los que ya me había referido en post anteriores. Aunque el con mas tranquilidad, constata como un equipo especializado vale mas que un gran equipo de personal poco cualificado. Y por supuesto, los proyectos ágiles suelen tener mas existo, o tienes mas predisposiciones a tenerlo, que un proyecto gestionado con metodologías mas rígidas. Algo que para muchos nos resulta mas que evidente, pero que en el mundo empresarial no.

• Modelo de negocios con Sergio Montoro. A expuesto de forma muy clara, las diferentes formas de ganar dinero con el software libre. Estoy bastante de acuerdo con la mayoría de las razones que ha dado. Aunque en el tema de servicios creo que hay mucho mas que decir. Pero eso depende sobre todo de tu modelo de negocio. A Sergio lo he conocido hace unas semanas, ya que he comenzado a desarrollar unos módulos para su software hipergate.

• Por ultimo, Francisco Peyrona, una persona muy importante en Sun Microsystem. Ha explicado que es java y que software tiene Sun, Glassfish y NetBeans. Ha sido divertido, y ha contado anécdotas interesantes.

Todas interesantes y con mucha información que poner en practica. Espero que pongas las ponencias en la web, aunque solo sen los pdfs.
Desde aquí mandar un saludo y las gracias a todos los ponentes, y espero que el próximo año siga la universidad promoviendo eventos de este tipo. A ver si el próximo año me toca a mi el iPod.

Ya tenemos casi a punto la nueva versión de GWT 2.0, esta en RC2, así que en breve tendremos una versión final.

Esta nueva versión promete muchas cosas nuevas e interesante, se nota como le han metido mano a fondo con el tema de WAVE.

He podido probarlo poco pero puedo decir que es fabuloso, una de las cosas que mas me molestaban era el hecho de tener que desarrollar con el navegador que trae en modo host. Que debe ser el motor de iexplorer 6, porque no hay forma de que vayan ciertas mejoras gráficas. Afortunadamente eso se ha terminado para siempre y ya podemos desarrollar en modo host, o como se llama ahora development mode, utilizando el firefox, y mejor aun, UTILIZANDO EL FIREBUG PARA ARREGLAR LA VISTA!!!!!. Ya no tenemos que compilar el proyecto para poder usar el firebug.

Trae muchas mas mejoras como el UIBinder, que permite montar las vistas con archivos xml. Aunque no he podido probarlo ya os iré informando de lo que vaya descubriendo.

¿Alguno lo ha probado? ¿Cual es vuestra opinión al respecto?

Vamos a tratar la gestión de beans de spring dentro de GWT. En principio no tiene nada de especial. Solo hay que arrancar el contexto de spring para poder solicitar los beans que queramos.

Despues de navegar mucho, pero que mucho, he encontrado 3 metodos:

El primero y más simple, cargar el archivo de configuración xml en cualquier momento

org.springframework.beans.factory.access.BeanFactoryLocator beanFactoryLocator = org.springframework.context.access.ContextSingletonBeanFactoryLocator.getInstance(“Archivo-configuracion.xml”);

beanFactoryReference = beanFactoryLocator.useBeanFactory(“BeanId”);

(org.springframework.context.ApplicationContext)beanFactoryReference.getFactory();

Esto puesto en algún singleto y en un método synchronized, es posible que no de muchos problemas, lo único es que en cada servicio habría que llamarlo explícitamente para usar los beans de spring, no siendo muy automatico.

Usando el ContextLoaderListener

Con unos pequeños cambios podemos hacer que sea la propia aplicación web quien carge el contexto al iniciar la aplicación.

Para ello, solo hay que poner el nuestro web.xml el siguiente código:

<context-param>

	<param-name>contextConfigLocation</param-name>

		<param-value>

        /WEB-INF/applicationContext.xml

		classpath:applicationContext.xml

	</param-value>

</context-param>

Teneis las dos formas de cargar el archivo, si esta en el contexto de la aplicación, directamente por su path. O si lo tenemos en algún paquete de nuestro classpath. El ya lo busca y lo carga.

Y después:

<listener>

	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

Que ya se encarga de cargar el archivo de configuración.Despues podemos solicitar el Bean de spring utilizando la siguiente instrucción.

ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(getServletContext());

(MyService)context.getBean(“myservice”);

No hace falta decir que esto ha de hacerse desde un servlet en el servidor, para poder tener acceso al contexto de la aplicación.

Para no tener que llamarlo constantemente en cada servlet, podemos extender RemoteServiceServlet de GWT y montarlo en llamadas que nos den los servicios.

public class SpringRemoteServiceServlet extends RemoteServiceServlet{

	private ApplicationContext getContext(){

		ServletContext sc = getServletContext();

		return WebApplicationContextUtils.getWebApplicationContext(sc);

	}

	protected MyService getMyService(){

		return (MyService)getContext().getBean("myService");

	}

}

Así solo tenemos que llamar en nuestro servlet al metodo del servicio correspondiente. Aun asi, no deja de ser un poco intrusivo, y el hecho de tener una llamada en medio de nuestro servlet del tipo getServicio(), marea un poco.

Inyección de dependencias

Este es el que más me gusta, cumple con la filosofía de inyección de dependencias de spring, y lo hace todo muy transparente. Este lo he encontrada de aquí. Esta en ingles, pero se entiende muy bien. Pero hare un resumen:

Al igual que hacíamos en el anterior punto, extendemos RemoteServiceServlet de GWT:

import java.lang.reflect.Field;

import java.util.HashSet;

import java.util.Set;

import org.apache.log4j.Logger;

import org.springframework.beans.factory.NoSuchBeanDefinitionException;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.web.context.support.WebApplicationContextUtils;

import com.google.gwt.user.server.rpc.RemoteServiceServlet;

/**

 * {@link RemoteServiceServlet} that automatically injects IoC dependency.

 * "org.springframework.beans.factory.annotation.Autowired" annotation is used

 * for marking which fields to inject into. Uses

 * {@link SpringApplicationContextLoader} to retrieve beans by name.

 *

 * Note that the current implementation will only inject "declared" fields, and

 * not inherited fields. Fields can be private, protected, package or public.

 * 

 * @author See Wah Cheng

 * @created 27 Jun 2008

 */

@SuppressWarnings("serial")

public class DependencyInjectionRemoteServiceServlet extends

		RemoteServiceServlet {

	protected static Logger logger = Logger

			.getLogger(DependencyInjectionRemoteServiceServlet.class);

	@Override

	public void init() throws ServletException {

		super.init();

		doDependencyInjection();

	}

	/**

	 * Carries out dependency injection. This implementation uses Spring IoC

	 * container.

	 * 

	 * @exception NoSuchBeanDefinitionException

	 *                if a suitable bean cannot be found in the Spring

	 *                application context. The current implementation looks up

	 *                beans by name

	 */

	protected void doDependencyInjection() {

		for (Field field : getFieldsToDependencyInject()) {

			try {

				boolean isFieldAccessible = field.isAccessible();

				if (!isFieldAccessible) {

					field.setAccessible(true);

				}

				field.set(this, WebApplicationContextUtils

						.getWebApplicationContext(getServletContext()).getBean(

								field.getName()));

				if (!isFieldAccessible) {

					field.setAccessible(false);

				}

				logger.debug("Dependency injection successful: "

						+ this.getClass().getName() + "." + field.getName());

			} catch (IllegalArgumentException e) {

				throw new RuntimeException(e);

			} catch (IllegalAccessException e) {

				throw new RuntimeException(e);

			}

		}

	}

	/**

	 * Find annotated fields to inject.

	 * 

	 * @return a list of all the annotated fields

	 */

	private Set getFieldsToDependencyInject() {

		Set fieldsToInject = new HashSet();

		Field[] fields = this.getClass().getDeclaredFields();

		for (Field field : fields) {

			if (field.getAnnotation(Autowired.class) != null) {

				fieldsToInject.add(field);

			}

		}

		return fieldsToInject;

	}

}

Esta es la clase que deberemos heredar en todos nuestros servicios. Y en el servicio en concreto debemos marcas la dependencia, en este ejemplo utilizan una anotación de spring, @Autowired. Si nos fijamos, cuando solicita los campos de la clase, utiliza reflection para buscar esa marca, y después busca el servicio en el contexto de spring que tiene en el contexto del servlet y lo asigna. Muy limpio y fácil de utilizar.