Posts Tagged ‘spring’

Llevo tiempo queriendo hacer una integración un poco mas limpia entre spring y gwt, y de paso empezar a usar maven de forma completa. Navegando por internet no he encontrado mucha información sobre esta complicada unión. Incluso en Google hay una pequeña pagina donde explica a grandes rasgos una posible integración. Pero no ha sido hasta hace poco que no he dado con alguien que explicara de forma clara como hacerlo.

La dirección de los tutoriales es esta http://krams915.blogspot.com/search/label/GWT, una web que interesante . Si estáis interesados, seguir los tutoriales.

Yo solo añadiré algunas aclaraciones, porque aunque esta bastante claro hay cosas que no me han funcionado.

M2eclipse

Este plugin me ha dado muchos problemas, hasta que me he dado cuenta de que era el y lo he erradicado por completo. Vamos a ver, no es que sea malo o no funcione, es que en mi caso particular me ha hecho muchos extraños. Para empezar, en un proyecto maven las librerías no están en el proyecto, si no que están en el repositorio local, con lo que el eclipse en algunas ocasiones se puede hacer un lío.  Solucionable copiando dichos archivos a la carpeta de la web. Aunque claro, ya empezamos con piados a mano de librerías. Y no importa que las tengas en el classpath, algunas no las coge, no me preguntéis por que.

Y lo mas raro de todo, los controller de spring-mvc no los cargaba, aunque si me cargaba los beans de spring security. Curiosamente las dos clases controlador que hace mención en el tutorial de arriba, no las cargaba, y claro, no encontraba las paginas. Después de muchas comprobaciones, y de ver que utilizando el maven a pelo para ponerlo en marcha si que funcionaba, llegue a esta conclusión.

Y el autor ha debido tener los mismos problemas porque utiliza la declaración de los beans de gwt por el xml, y comenta que hay algún tipo de conflicto con las anotaciones y gwt. Pero puedo confirmar que los servicios de gwt se pueden configurar por anotaciones sin ningún problema.

Así que para evitar problemas, recomiendo utilizar maven como siempre, pero a la hora de ponerlo en eclipse, utilizar mvn eclipse:eclipse, que eso no falla y podréis manejar el proyecto sin problemas, depurar y ejecutar con el plugin de google.

Plugin de google

En este caso solo una aclaración, que ademas la tenéis en la página del mojo, la web donde esta el archetype de gwt, y es que tenéis que mover el archivo de configuración de gwt, modulo.gwt.xml, desde la carpeta de fuentes resources, /src/main/resources, a la carpeta de fuentes java, /src/main/java. Para que el plugin lo reconozca y no tenga problema en ejecutarlo.

gwt-widget

Esta librería te la una implementación sencilla de la solución que propuso google. No tiene ningún problema y funciona muy bien. El inconveniente, que lleva tiempo parada y no se si continuara, aunque por el momento a mi me sirve.

También hay que tener en cuenta que no esta en repositorios maven, con lo que hay que bajárselo e instalarlo en el repositorio local para que funcione bien con maven. Un ejemplo:

mvn install:install-file -DgroupId=org.gwtwidget -DartifactId=gwtwidget -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file

Luego la incluis en vuestro pom tal que así:

		<dependency>
			<groupId>gwt.widget</groupId>
			<artifactId>gwtwidget</artifactId>
			<version>1.0</version>
		</dependency>

Poco mas puede aportar, me ha llevado algún tiempo sacar estas conclusiones pero en el fondo es sencillo.

Queda pendiente un post de como utilizar spring security para aplicar seguridad a una aplicación gwt. Ahora que tengo esto montado y funcionando no me llevara mucho tiempo.

Hacia tiempo que no escribía un post técnico y ya ha llegado el momento. Recientemente, desarrollando una aplicación a medida para un cliente, me he visto en la necesidad de conectar una aplicación de escritorio con una aplicación web. En los años que llevo programando no he tenido necesidad de realizar esta operativa, muchas veces ha sido conectar una aplicación web con otras aplicaciones, tanto web, servidores de diferentes tipos como de escritorio, pero han sido siempre desde la perspectiva de la lógica de negocio en el servidor, consumiendo servicios web, accediendo a base de datos o incluso leyendo archivos. Esto es distinto, tengo que ofrecer acceso a mi aplicación web para aplicaciones de escritorio. Nada complicado si se utilizan webservices. Pero he aprovechado la coyuntura para probar unas nuevas herramientas, spring roo, que genera de forma espectacular una aplicación web y al que ya dedicare un post con mas tranquilidad. Por el momento decir que genera aplicaciones con JPA en Hiberanate (mas bien en cualquier cosa) y spring para el negocio. Ademas de hacer un scaffold de las web con GWT. Para la seguridad puedes incluir spring security, que es lo que yo he introducido. Hasta aquí todo bien, funciona perfectamente y sin ningún problema, puedes controlar el acceso por métodos de negocio con simples tag, muy fácil. Ahora viene la parte en que conectamos la aplicación de escritorio, en mi caso con una aplicación swing (por cierto con netbeans y matisse, muy sencillo también). Spring te ofrece un montón de opciones de interconexión, RMI directamente y de forma sencilla, HTTP-Invoke o webservices, entre muchos. He probado RMI y muy contento, pero al final me he decantado por HTTP-invoke por varios motivos:

• RMI necesita configurarse ademas un puerto concreto, complicando la instalación en según que sitios. Si el servidor y la red son tuyos no hay muchos problemas, pero si utilizas algo como la PAAS de google puedes tener algunos problemas. En cambio HTTP-Invoke usa el mismo puerto 80.

• Rendimiento: Tanto RMI como HTTP-Invoke tienen muy buenos rendimientos, ambos usan serialización de objetos.

• Configuración, al ir por el puerto 80 no requiere configuración extra de seguridad.

El problema lo tuve en la seguridad, como configurar la seguridad y realizar un login remoto, que es lo que voy a explicar aquí.

Servidor

Para configurar el lado del servidor hay que realizar los siguientes pasos:

• Crear una capa de servicios: para ello creamos unas clases en nuestro código que ofrecerá los servicios que nos interesen.

public interface ServicioSaludo {

@Secured(“ROLE_ADMIN”)

public String getSaludo();

}

@Service(“saludador”)

public class ServicioSaludoImpl implements ServicioSaludo {

@Override

public String getSaludo() {

return “Hola”;

}

}

Es en la interfaz donde declaramos la seguridad con los tags @Secured. Luego pondré la configuración básica de seguridad.

El tag @Service le indica a spring que es un bean y que debe nombrarlo como saludador, de esta manera no hará falta ponerlo expresamente en el xml de configuración. Claro que para que funcione debéis configurar vuestro spring con el siguiente código.

<context:component-scan base-package=”paquete”>

Si no, simplemente lo declaráis expresamente como un bean

<bean name=”saludador” class=”paquete.ServicioSaludoImpl”/>

Ya tenemos el servicio declarado, ahora lo exponemos con HTTP-Invoker.

<bean name=”/saludadorHTTP” class=”org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter”>

<property name=”service” ref=”saludador”/>

<property name=”serviceInterface” value=”paquete.ServicioSaludo”/>

</bean>

/saludadorHTTP indica donde estará accesible, después ponemos con que lo exponemos, e indicamos las clases que queremos exponer.

Aquí tenéis el archivo de configuración de seguridad.

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans:beans xmlns=”http://www.springframework.org/schema/security”

xmlns:beans=”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-3.0.xsd

http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd”>

<http auto-config=”true” use-expressions=”true”>

<intercept-url pattern=”/login.*” access=”permitAll”/>

<intercept-url pattern=”/**” access=”isAuthenticated()” />

<form-login/>

<anonymous />

<http-basic />

</http>

<global-method-security secured-annotations=”enabled”/>

<!– Configure Authentication mechanism –>

<authentication-manager alias=”authenticationManager”>

<authentication-provider>

<user-service>

<user name=”admin” password=”admin” authorities=”ROLE_ADMIN”/>

</user-service>

</authentication-provider>

</authentication-manager>

</beans:beans>

use-expressions sirve para utilizar las nuevas forma de definir las seguridad, bastante mas completas.

Global-method-security sirve para poder utilizar las anotaciones de seguridad en las interfaces que hemos usado antes.

En cuanto a lo demás, es básico en seguridad de spring, así que no haré mas comentarios.

Ahora cargamos otro dispacher de spring en el web.xml, se pueden tener todos los que se quieran, y es recomendable separarlo, si tenéis uno para el MVC de spring, podéis dejarlo intacto y añadir este otro solo para las conexiones remotas.

<servlet>

<servlet-name>remoting</servlet-name>

<servlet-class>

org.springframework.web.servlet.DispatcherServlet

</servlet-class>

<init-param>

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

<param-value>/WEB-INF/spring/remoting-servlet.xml</param-value>

</init-param>

<load-on-startup>2</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>remoting</servlet-name>

<url-pattern>/remoting/*</url-pattern>

</servlet-mapping>

Varias cosas, para los que no lo sepan, el contextConfigLocation no es necesario, siempre y cuando llaméis al archivo con la nomenclatura servletName-servlet.xml y ubicado en WEB-INF/classes. Si lo queréis en otro sitio y con otro nombre pues se pone.

Aquí nos quedamos con la URI /remoting, que se usara en el cliente. Con esto ya tendremos configurado el servidor.

Cliente

Le toca al cliente, en este caso utilizare una simple aplicación de consola. Necesitaremos varias cosas:

• Las interfaces del servidor: podemos empaquetar solo las interfaces del servidor y añadirlas nuestro proyecto cliente.
• Las librerias de spring: tanto el core como security.

Ahora configuramos nuestra aplicación creando un archivo de configuración cliente para spring, por ejemplo cliente.xml, e introducimos lo siguiente:

<bean id=”servicio”>

<property name=”serviceUrl” value=”http://localhost/remoting/saludadorHTTP”/>

<property name=”serviceInterface” value=”paquete.ServicioSaludo”/>

<property name=”httpInvokerRequestExecutor”>

<ref bean=”httpInvokerRequestExecutor”/>

</property>

</bean>

<bean id=”httpInvokerRequestExecutor”     class=”org.springframework.security.remoting.httpinvoker.AuthenticationSimpleHttpInvokerRequestExecutor”/>

La dirección del servicio donde lo tengáis, en mi caso en localhost, seguido de remoting que es donde mapeamos el servlet para servicios remotos y por último la dirección del servicio concreto que configuramos en el archivo xml de spring del servidor. Ademas cargamos el bean para que lo use de autenticado.

Y nos vamos al main de la clase cliente.

//Creamos una autenticación con el usuario y contraseña

Authentication request = new UsernamePasswordAuthenticationToken(“admin”, “admin”);

//Este es el contexto que extiende del servidor, es aqui donde nos logeamos

SecurityContextHolder.getContext().setAuthentication(request);

//Cargamos el archivo de configuración

ClassPathXmlApplicationContext contexto = new ClassPathXmlApplicationContext(“cliente.xml”);

 

ServicioSaludador servicio = (ServicioSaludador) contexto.getBean(“servicio”);

String cadena = servicio.getSaludo();

Y ya esta, facilísimo.

Bueno, quien dice un main dice una aplicación swing, es la mar de sencillo, yo por el momento uso netbeans que funciona muy bien.

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.