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.

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

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?

Continuando con el tema del curso de Groovy y Grails, hoy toca hablar de lo que es Grails.

Grails es un framework web basado en MVC, que mediante comandos Ant, o como lo llaman Gant, se va construyendo la aplicación. Sigue una metodología de desarrollo basado en el Dominio, y por debajo genera todo con Spring, Hibernate y GSP, que son como las JSP de toda la vida, pero con tags de grails y lenguaje Groovy.

Una de las características mas interesantes que posee es el scafloinding. Que mediante unas pocas líneas y comandos, genera todo el CRUD, desde la vista hasta la base de datos, pasando por el controlador, DAO y servicios necesarios.

Otro concepto interesante son los plugin que es una forma de añadir seguridad, ajax, test y cualquier otra funcionalidad, herramienta o servicio que necesitemos de una forma fácil, aunque eso es un poco relativo.

En principio parece una herramienta para el desarrollo de aplicaciones de una cierta complejidad de forma realmente rápida, como ejemplo tenemos a jobsket, realizado en grails.

Aunque como todo, hasta que no te metes en el ajo no ves realmente como es, he iniciado un proyecto con unos amigos para desarrollar una aplicación en dicha tecnología, que ya iré comentado.

Si alguno ha utilizado alguna de estas tecnologías, estaré muy agradecido de que comparta sus experiencias conmigo.

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.