Spring, un Framework para desarrollar aplicaciones Web Java

Sé diferente, intégrate Mca088 Manual Spring, un Framework para desarrollar aplicaciones Web Java Autor: Orlando Gutiérrez Fecha: 01/01/2011 Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 1

ÍNDICE: L1 DESARROLLO DE APLICACIONES WEB...3 L2 DESARROLLO DE APLICACIONES EN MÚLTIPLES CAPAS...4 L3 MODELO MVC...5 L4 FRAMEWOKS DE DESARROLLO...6 L5 QUÉ ES SPRING?...6 L6 REQUISITOS SPRING...7 L8 ARQUITECTURA SPRING...9 L9 PROGRAMACIÓN ORIENTADA POR ASPECTOS AOP... 10 L10 PATRÓN IOC INVERSIÓN DEL CONTROL... 11 L11 DESARROLLO DE UNA APLICACIÓN Y CONFIGURACIÓN DEL AMBIENTE: INDEX.JSP, TOMCAT, WEB.XML... 16 L12 DESARROLLO Y CONFIGURACIÓN DE LAS CAPAS DE VISTA Y LOS CONTROLADORES... 28 L13 DESARROLLO LA LÓGICA DEL NEGOCIO... 33 L14 DESARROLLO DE LA INTERFAZ WEB: AGREGAR UN FORMULARIO, AGREGAR UN CONTROLADOR DE FORMULARIO... 41 L15 IMPLEMENTAR PERSISTENCIA A TRAVÉS DE BASES DE DATOS... 51 L16 JDBC... 54 L17 INTEGRAR LAS CAPAS... 60 L18 AGREGAR SERVICIOS... 64 L19 MANEJAR TRANSACCIONES... 66 L20 MANEJAR POOL DE CONEXIONES... 66 L21 DESARROLLAR SCRIPTS PARA EL BUILD... 68 Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 2

L1 DESARROLLO DE APLICACIONES WEB En la ingeniería de software se denomina aplicación web a aquellas aplicaciones donde los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador. En otras palabras, es una aplicación software codificada en un lenguaje soportado por los navegadores web donde se confía la ejecución al navegador. Las aplicaciones web son populares debido a lo práctico del navegador web como cliente ligero, a la independencia del sistema de operación, así como a la facilidad para actualizar y mantener aplicaciones web sin distribuir e instalar software a miles de usuarios potenciales. Existen aplicaciones como los webmails, wikis, weblogs, tiendas en línea; siendo ejemplos bien conocidos de aplicaciones web. Es importante mencionar una página Web puede contener elementos permitiendo una comunicación activa entre el usuario y la información. Esto permite al usuario acceder a los datos de modo interactivo, porque la página responderá a cada una de sus acciones, como por ejemplo rellenar y enviar formularios, participar en juegos diversos y acceder a manejadirores de base de datos de todo tipo. VENTAJAS - Ahorra tiempo: Se pueden realizar tareas sencillas sin necesidad de descargar ni instalar ningún programa. - No existen problemas de compatibilidad: Basta tener un navegador actualizado para poder utilizarlas. - No ocupan espacio en el disco duro. - Actualizaciones inmediatas: Como el software lo gestiona el propio desarrollador, cuando el usuario se conectanos está usando siempre la última versión lanzada. - Consumo de recursos bajo: Toda (o gran parte) de la aplicación no se encuentra en el computador del usuario, muchas de las tareas realizas por el software no consumen recursos nuestros porque se realizan desde el servidor. - Multiplataforma: Se pueden utilizar desde cualquier sistema de operación porque sólo es necesario tener un navegador. - Portables: Es independiente del computador donde se utilice (un PC, un portátil...) porque se accede a través de una página web (sólo es necesario disponer de acceso a Internet). La reciente tendencia al acceso a las aplicaciones web a través de teléfonos móviles requiere sin embargo un diseño específico de los archivos CSS para no dificultar el acceso de estos usuarios. - La disponibilidad suele ser alta porque el servicio se ofrece desde múltiples localizaciones para asegurar la continuidad del mismo. - Los virus no dañan los datos porque éstos están guardados en el servidor de la aplicación. - Colaboración: Como el acceso al servicio se realiza desde una única ubicación es sencillo el acceso y el intercambio de datos por parte de varios usuarios.. - Los navegadores ofrecen cada vez más y mejores funcionalidades para crear aplicaciones web con interfaces del tipo rich (RIAs). Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 3

INCONVENIENTES - Generalmente ofrecen menos funcionalidades a las aplicaciones de escritorio. Porque las funcionalidades a realizar desde un navegador son más limitadas a las realizadas desde el sistema de operación. Pero cada vez los navegadores están más preparados para mejorar en este aspecto. La aparición de HTML 5 representa un hito en este sentido. Es posible añadir funcionalidades a estas aplicaciones gracias al uso de Aplicaciones de Internet tipo rich. - La disponibilidad depende de un tercero, el proveedor de la conexión a internet o el proveedor del enlace entre el servidor de la aplicación y el cliente. La disponibilidad del servicio está supeditada al proveedor. 1 L2 DESARROLLO DE APLICACIONES EN MÚLTIPLES CAPAS A continuación, se muestra un ejemplo de una aplicación J2EE, mostrando una pequeña aplicación Enterprise multicapa consistiendo en una página HTML, un servlet y un Bean de sesión. La pequeña aplicación cliente de ejemplo acepta entrada de usuario a través de un formulario HTML invocando un servlet. El servlet usa el API JNDI (Java Naming and Directory Interface ) para buscar un Bean de sesión realizando los cálculos por él. Este ejemplo es una aplicación pequeña porque el servlet no ejecuta ninguna lógica de negocio. El sencillo cálculo lo realiza un Bean de sesión ejecutándose en el servidor de aplicaciones J2EE. Por eso el cliente es pequeño, porque no maneja el proceso; lo hace el Bean de sesión. Las aplicaciones multi-capa pueden consistir en 3 ó 4 capas. Como se ve en la figura siguiente, el ejemplo multicapa tiene cuatro capas. La arquitectura de tres capas extiende al cliente estándar de dos capas y el modelo del servidor situando un servidor de aplicaciones multi-capa entre la aplicación cliente no-basada-en-web y la base de datos final. La arquitectura de cuatro capas extiende el modelo de tres capas reemplazando la aplicación cliente con un navegador Web y una página HTML potenciada con las tecnologías servlet/javaserver Pages. El objetivo principal del desarrollo multi-capas es lograr independencia total de las capas, mínimo acoplamiento entre ellas permitiendo modificar en la totalidad una capa sin afectar el resto. Por ejemplo en la arquitectura Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 4

mostrada anteriormente se podría cambiar de manejador de Base de Datos de mysql a PostgreSQL sin afectar en el resto de las capas. L3 MODELO MVC Spring está basado en un patrón clásico del diseño web conocido como arquitectura MVC, formado por tres niveles: El Modelo representa la información funcional de la aplicación, la lógica de negocio. La Vista transforma el modelo en una página web permitiendo al usuario interactuar con ella. El Controlador se encarga de procesar las interacciones del usuario y realizar los cambios apropiados en el modelo o en la vista. La siguiente figura ilustra el funcionamiento del patrón MVC. La arquitectura MVC separa la lógica de negocio (el modelo) y la presentación (la vista) facilitando el mantenimiento de las aplicaciones. Si por ejemplo una misma aplicación debe ejecutarse tanto en un navegador estándar como un un navegador de un dispositivo móvil, solamente es necesario crear una vista nueva para cada dispositivo; manteniendo el controlador y el modelo original. El controlador se encarga de aislar al modelo y a la vista de los detalles del protocolo utilizado para las peticiones (HTTP, consola de comandos, email, etc.). El modelo se encarga de la abstracción de la lógica relacionada con los datos, Y la vista y las acciones son independientes de, por ejemplo, el tipo de administrador de bases de datos utilizado por la aplicación. L4 FRAMEWOKS DE DESARROLLO Un framework simplifica el desarrollo de una aplicación mediante la automatización de los patrones más comúnmente empleados para el desarrollo de software en un Lenguaje de Programación. Spring es un framework para Java facilitando el patrón de desarrollo MVC (Modelo Vista Controlador). Un framework proporciona: Estructuración del código fuente, forzando al desarrollador a crear código más legible y más fácil demantener. Facilita la programación de aplicaciones, encapsulando operaciones complejas en instrucciones sencillas. Spring es framework diseñado para optimizar el desarrollo de las aplicaciones web. En primer lugar, separa la lógica de negocio, la lógica de servidor y la capa de presentación de la aplicación web. Proporciona varias herramientas y Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 5

clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación (lógica del negocio). Lo más importante al utilizar un framework es que no se reinventa la rueda cada vez que se desarrolla una nueva aplicación web. Spring está desarrollado completamente con Java, ha sido experimentado en varios proyectos reales y se utiliza en sitios web de comercio electrónico. Spring es compatible con la mayoría de los manejadores de bases de datos (DBMS), por soportar una abstracción JDBC: como MySQL, PostgreSQL, Oracle y Microsoft SQL Server. Se puede ejecutar en todas las plataformas donde se ejecuta Java. L5 QUÉ ES SPRING? Spring es un framework de aplicaciones Java/J2EE desarrollado usando licencia de OpenSource. Se basa en una configuración empleando javabeans bastante simple. Es potente en cuanto a la gestión del ciclo de vida de los componentes y fácilmente ampliable. Es interesante el uso de programación orientada a aspectos (IoC). Tiene plantillas permitiendo un más fácil uso de Hibernate, ibatis, JDBC..., se integra "de fábrica" con Quartz, Velocity, Freemarker, Struts, Webwork2 y tiene un plugin para eclipse. Ofrece un ligero contenedor de bean para los objetos de la capa de negocio, DAOs y repositorio de Datasources JDBC y sesiones Hibernate. Mediante un xml se define el contexto de la aplicación siendo una potente herramienta para manejar objetos Singleton o factorias que necesitan su propia configuración. El objetivo de Spring es no ser intrusivo, aquellas aplicaciones configuradas para usar beans mediante Spring no necesitan depender de interfaces o clases de Spring, pero obtienen su configuración a través de las propiedades de sus beans. Este concepto puede ser aplicado a cualquier entorno, desde una aplicación J2EE a un applet. Como ejemplo se puede pensar en conexiones a base de datos o de persistencia de datos, como Hibernate, la gestión de transacciones genérica de Spring para DAOs es muy interesante. La meta a conseguir es separar los accesos a datos y los aspectos relacionados con las transacciones, para permitir objetos de la capa de negocio reutilizables no dependientes de ninguna estrategia de acceso a datos o transacciones. Spring ofrece una manera simple de implementar DAOs basados en Hibernate sin necesidad de manejar instancias de sesion de Hibernate o participar en transacciones. No necesita bloques try-catch, el cual innecesario para el chequeo de transacciones. Se podría conseguir un método de acceso simple a Hibernate con una sola línea. QUÉ PROPORCIONA? Spring proporciona: Una potente gestión de configuración basada en JavaBeans, aplicando los principios de Inversión de Control (IoC). Esto hace la configuración de aplicaciones, rápida y sencilla. Ya no es necesario tener singletons ni archivos de configuración, una aproximación consistente y elegante. Estas definiciones de beans se realizan en el contexto de aplicación. Una capa genérica de abstracción para la gestión de transacciones, permitiendo gestores de transacción añadibles (pluggables), y haciendo sencilla la demarcación de transacciones sin tratarlas a bajo nivel. Se incluyen estrategias genéricas para JTA y un único JDBC DataSource. En contraste con el JTA simple o EJB CMT, el soporte de transacciones de Spring no está atado a entornos J2EE. Una capa de abstracción JDBC ofreciendo una significativa jerarquía de excepciones (evitando la necesidad de obtener de SQLException los códigos asignados por cada manejador de base de datos), simplificando el manejo de errores, y reduciendo considerablemente la cantidad de código necesario. Integración con Hibernate, JDO e ibatis SQL Maps en términos de soporte a implementaciones DAO y estrategias con transacciones. Especial soporte a Hibernate añadiendo convenientes características de IoC, y solucionando muchos de los comunes problemas de integración de Hibernate. Todo ello cumpliendo con las transacciones genéricas de Spring y la jerarquía de excepciones DAO. Funcionalidad AOP, totalmente integrada en la gestión de configuración de Spring. Se puede aplicar AOP a cualquier objeto gestionado por Spring, añadiendo aspectos como gestión de transacciones declarativa. Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 6

Con Spring se puede tener gestión de transacciones declarativa sin EJB, incluso sin JTA, si se utiliza una única base de datos en un contenedor Web sin soporte JTA. Un framework MVC (Model-View-Controller), construido sobre el núcleo de Spring. Este framework es altamente configurable vía interfaces y permite el uso de múltiples tecnologías para la capa vista como pueden ser JSP, Velocity, Tiles, itext o POI. De cualquier manera una capa modelo realizada con Spring puede ser fácilmente utilizada con una capa web basada en cualquier otro framework MVC, como Struts, WebWork o Tapestry. L6 REQUISITOS SPRING Para poder codificar en Spring se necesitan varias librerías. Para facilitar la ejecución se recomienda tener instalado un ide de desarrollo java como eclipse o netbeans para poder navegar por el código con soltura. Para programar con Spring se requieren las siguientes librerías: Spring en http://www.springframework.org existe un archivo Springframework-whith-dependences.zip conteniendo todas las clases necesarias para ejecutar todas las herramientas de spring. Java SDK 1.5 Ant 1.7 Apache Tomcat 6.0.14 Eclipse 3.3 (Recomendado, pero no necesario) Eclipse 3.3 Europa (http://www.eclipse.org/europa) en conjunto con el Proyecto Web Tools Platform (WTP) Project (http://www.eclipse.org/webtools) y el proyecto Spring IDE Project (http://www.springide.org) proven un excelente ambiente para el desarrollo web. Se puede utilizar una variación del software aquí mencionado. Por ejemplo, se puede utilizar NetBeans o IntelliJ en lugar de Eclipse o Jetty en lugar de Tomcat. L7 FRAMEWORK SPRING El Spring Framework (también conocido simplemente como Spring) es un framework de código abierto para desarrollo de aplicaciones en la plataforma Java. La primera versión fue escrita por Rod Jonhson. El framework fue lanzado inicialmente bajo Apache 2.0 License en junio de 2003. El primer gran lanzamiento hito fue la versión 1.0, apareciendo en marzo de 2004 y fue seguida por otros hitos en septiembre de 2004 y marzo de 2005. Aunque Spring Framework no obliga a utilizar un modelo de programación en particular, se ha popularizado en la comunidad de programadores en Java al ser considerado como una alternativa y sustituto del modelo de Enterprise JavaBean. Por su diseño, el framework ofrece mucha libertad a los desarrolladores en Java y soluciones muy bien documentadas y fáciles de usar para las prácticas comunes en la industria. Las características fundamentales de este framework pueden emplearse en cualquier aplicación desarrollada en Java. Existen muchas extensiones y mejoras para construir aplicaciones basadas en web por encima de la plataforma empresarial de Java (Java Enterprise Platform). A partir de 2009 las actualizaciones del producto (en su forma binaria) estarán disponibles únicamente para la última versión publicada del Framework. Para acceder a las actualizaciones en forma binaria para versiones anteriores se deberá pagar una subscripción. Sin embargo, estas actualizaciones estarán disponibles libremente (y gratuitamente) en forma de código fuente en los repositorios públicos del proyecto. HISTORIA Los primeros componentes evolucionando hacia Spring Framework fueron escritos por Rod Johnson en el año 2000, mientras trabajaba como consultor independiente para sus clientes en la industria financiera en Londres. Rod Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 7

Johnson amplió su código para sintetizar su visión acerca de cómo las aplicaciones trabajando con varias partes de la plataforma J2EE podían llegar a ser más simples y más consistentes a aquellas utilizadas por los desarrolladores y las compañías. En el año 2001 los modelos dominantes de programación para aplicaciones basadas en web eran ofrecidas por el API Java Servlet y los Enterprise JavaBeans, ambas especificaciones creadas por Sun Microsystems en colaboración con otros distribuidores y partes interesadas disfrutando de gran popularidad en la comunidad Java. Las aplicaciones no basadas en web, como las aplicaciones basadas en cliente o aplicaciones en batch, podían ser escritas con base en herramientas y proyectos de código abierto o comerciales proveyendo las características requeridas para aquellos desarrollos. Rod Johnson es reconocido por crear un framework basado en las mejores prácticas aceptadas, y ello las hizo disponibles para todo tipo de aplicaciones, no sólo aquellas basadas en web. Se formó un pequeño equipo de desarrolladores para trabajar en extender el framework y un proyecto fue creado en Sourceforge en febrero de 2003. Después de trabajar en su desarrollo durante más de un año lanzaron una primera versión (1.0) en marzo de 2004. Después de este lanzamiento Spring ganó mucha popularidad en la comunidad Java, debido en parte al uso de Javadoc y de una documentación de referencia por encima del promedio de un proyecto de código abierto. Sin embargo, Spring Framework también fue duramente criticado en 2004 y sigue siendo el tema de acalorados debates. Al tiempo en que se daba su primer gran lanzamiento muchos desarrolladores y líderes de opinión vieron a Spring como un gran paso con respecto al modelo de programación tradicional; esto era especialmente cierto con respecto a Enterprise JavaBeans. Una de las metas de diseño de Spring Framework es su facilidad de integración con los estándares J2EE y herramientas comerciales existentes. Esto quita en parte la necesidad de definir sus características en un documento de especificación elaborado por un comité oficial y que podría ser criticado. Spring Framework hizo que aquellas técnicas que resultaban desconocidas para la mayoría de programadores se volvieran populares en un periodo muy corto de tiempo. El ejemplo más notable es la inversión de control. En el año 2004, Spring disfrutó de unas altísimas tasas de adopción y al ofrecer su propio framework de programación orientada a aspectos (aspect-oriented programming, AOP)consiguió hacer más popular su paradigma de programación en la comunidad Java. En 2005 Spring superó las tasas de adopción del año anterior como resultado de nuevos lanzamientos y más características fueron añadidas. El foro de la comunidad formada alrededor de Spring Framework (The Spring Forum) arrancando a finales de 2004 también ayudó a incrementar la popularidad del framework y desde entonces ha crecido hasta llegar a ser la más importante fuente de información y ayuda para sus usuarios. L8 ARQUITECTURA SPRING El objetivo central de Spring es permitir la reutilización de objetos de negocio y de acceso a datos, no atados a servicios J2EE específicos. Estos objetos pueden ser reutilizados tanto en entornos J2EE (Web o EJB), aplicaciones standalone, entornos de pruebas, etc. sin ningún problema. La arquitectura en capas de Spring ofrece mucha de flexibilidad. Toda la funcionalidad está construida sobre los niveles inferiores. Por ejemplo se puede utilizar la gestión de configuración basada en JavaBeans sin utilizar el framework MVC o el soporte AOP. Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 8

L9 PROGRAMACIÓN ORIENTADA POR ASPECTOS AOP QUÉ ES AOP? AOP son las siglas en ingles de Programación orientada al aspecto (Aspect Oriented Programming). La definición más simple de AOP es una manera de eliminar codigo duplicado. Java es un lenguaje orientado a objetos y permite crear aplicaciones usando una determinada jerarquía de objetos, sin embargo esto no permite una manera simple de eliminar código repetido en aquellos objetos que no pertenecen a la jerarquía. AOP permite controlar tareas. En AOP se utilizarán conceptos como interceptor, inspeccionando el código a ejecutar, permitiendo por lo tanto realizar ciertas acciones como: escritura de trazas cuando el método es llamado, modificar los objetos devueltos o envío de notificaciones. INTRODUCCIÓN Cuando apareció la programación Orientada a Objetos (OO) en el desarrollo de software, tuvo un efecto dramático en cómo se desarrollaba éste. Los desarrolladores podían visualizar sistemas como grupos de entidades y la interacción entre esas entidades, permitiendo realizar sistemas más grandes y más complicados y desarrollarlos en mucho menos tiempo. El único problema con la programación OO es que es esencialmente estática, y un cambio en los requerimientos puede tener un profundo impacto en el tiempo de desarrollo. Consideremos un ejemplo: se desarrolla una sencilla aplicación web utilizando servlets como punto de entrada, donde un servlet acepta los valores de un formulario HTML, los une a un objeto, lo pasa a la aplicación para procesarlo y luego devuelve una respuesta al usuario. La primera versión del servlet podría ser muy simple, con la cantidad de código mínima necesaria para cumplir el papel a desempeñar. Sin embargo, el código crece en tres o cuatro veces su tamaño original debido a los requerimientos secundarios como el manejo de excepciones, la seguridad, y el logging implementado. Se utiliza el término requerimientos secundarios porque un servlet no debería Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 9

saber nada sobre el loggin o los mecanismos de seguridad a utilizar; su función principal es aceptar una entrada y procesarla. AOP ayuda a modificar dinámicamente el modelo estático para incluir el código requerido para cumplir los requerimientos secundarios sin tener que modificar el modelo estático original (de echo, ni siquiera se requiere el código original). Mejor aún, normalmente se puede tener este código adicional en una única localización en vez de tenerlo repartido por el modelo existente, como se haría si se se estuviera usando sólo OO. TERMINOLOGÍA Aquí se presenta la termonología estándar para ayudar a entender los conceptos. Cross-cutting concerns (problema cruzado): Incluso aunque la mayoría de las clases de un modelo OO realizarán una función sencilla y específica, normalmente comparten requerimientos secundarios comunes con otras clases. Por ejemplo, se puede agregar logging a las clases dentro de la capa de acceso a los datos y también a las clases de la capa de presentación siempre que un thread entre o salga de un método. Incluso aunque la funcionalidad primaria de cada clase sea muy diferente, el código necesario para realizar la segunda funcionalidad es casi siempre idéntico. Advice (Consejo): Este es el código adicional a aplicar a nuestro modelo existente. En el ejemplo, es el código de logging a aplicar siempre que el thread entre o salga de un método. Point-cut (punto de corte): Este es el término dado al punto de ejecución en flujo de la aplicación donde se necesita aplicar el problema cruzado. En el ejemplo, se tiene un punto de corte cuando el thread entra a un método, y otro punto de corte cuando el thread sale de ese método. Aspect (Aspecto): La combinación del punto de corte y el consejo es conocida como un aspecto. En el siguiente ejemplo, se añade un aspecto de login a la aplicación definiendo un punto de corte y dándole el consejo correcto. Existen muchas otras facetas AOP, como las introducciones (donde se pueden añadir interfaces/métodos/campos a clases existentes), conteniendo un potencial tremendo para los desarrolladores. CONCEPTOS Aspect (Aspecto) es una funcionalidad transversal (cross-cutting) a implementar de forma modular y separada del resto del sistema. El ejemplo más común y simple de un aspecto es el logging (registro de sucesos) dentro del sistema, porque necesariamente afecta a todas las partes del sistema generando un suceso. Join point (Punto de Cruce o de Unión) es un punto de ejecución dentro del sistema donde un aspecto puede ser conectado, como una llamada a un método, el lanzamiento de una excepción o la modificación de un campo. El código del aspecto será insertado en el flujo de ejecución de la aplicación para añadir su funcionalidad. Advice (Consejo) es la implementación del aspecto, es decir, contiene el código que implementa la nueva funcionalidad. Se insertan en la aplicación en los Puntos de Cruce. Pointcut (Puntos de Corte) define los Consejos a aplicar en cada Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones de nombres (de clases, métodos o campos), e incluso dinámicamente en tiempo de ejecución según el valor de ciertos parámetros. Introduction (Introducción) permite añadir métodos o atributos a clases ya existentes. Un ejemplo es la creación de un Consejo de Auditoría manteniendo la fecha de la última modificación de un objeto, mediante una variable y un Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 10

método setultimamodificacion(fecha), introducidos en todas las clases (o sólo en algunas) para proporcionarles esta nueva funcionalidad. Target (Destinatario) es la clase aconsejada, la clase objeto de un consejo. Sin AOP, esta clase debería contener su lógica, además de la lógica del aspecto. Proxy (Resultante) es el objeto creado después de aplicar el Consejo al Objeto Destinatario. El resto de la aplicación únicamente soportará al Objeto Destinatario (pre-aop) y no al Objeto Resultante (post-aop). Weaving (Tejido) es el proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario. L10 PATRÓN IOC INVERSIÓN DEL CONTROL Spring se basa en IoC. IoC es lo conocido como El Principio de Inversión de Dependencia, Inversion of Control" (IoC) o patrón Hollywood ("No nos llames, nosotros le llamaremos") consiste en: Un Contenedor manejando objetos por usted. El contenedor generalmente controla la creación de estos objetos. Por decirlo de alguna manera, el contenedor hace los new de las clases java para que no los realice usted. El contenedor resuelve dependencias entre los objetos contenidos. Estos puntos son suficientes y necesarios para poder hablar de una definición básica de IoC. Spring proporciona un contenedor manejando todo lo realizado con los objetos del IoC. Debido a la naturaleza del IoC, el contenedor más o menos ha definido el ciclo de vida de los objetos. Y, finalmente, el contenedor resuelve las dependencias entre los servicios controlados por él. La Inversión de Control es un patrón de diseño pensado para permitir un menor acoplamiento entre componentes de una aplicación y fomentar así el reuso de los mismos. UN PROBLEMA, UNA SOLUCIÓN Como todo patrón, comienza planteando un problema y el viene a resolver. Muchas veces, un componente tiene dependencias de servicios o componentes cuyos tipos concretos son especificados en tiempo de diseño. En el ejemplo de la imagen, clase A depende de ServiceA y de ServiceB. Los problemas planteados son: Al reemplazar o actualizar las dependencias, se necesita cambiar el código fuente de la clase A. Las implementaciones concretas de las dependencias debem estar disponibles en tiempo de compilación. Las clases son difíciles de testear aisladamente porque tienen directas definiciones a sus dependencias. Esto significa que las dependencias no pueden ser reemplazadas por componentes stubs o mocks. Las clases tienen código repetido para crear, localizar y gestionar sus dependencias. Aquí la solución pasa por delegar la función de seleccionar una implementación concreta de las dependencias a un componente externo. Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 11

El control de cómo un objeto A obtiene la referencia de un objeto B es invertido. El objeto A no es responsable de obtener una referencia al objeto B sino que es el Componente Externo el responsable de esto. Esta es la base del patrón IoC. USOS El patrón IoC se puede utilizar cuando: Se desea desacoplar las clases de sus dependencias de manera de que las mismas puedan ser reemplazadas o actualizadas con muy pocos o casi ningún cambio en el código fuete de sus clases. Se desea escribir clases que dependan de clases cuyas implementaciones no son conocidas en tiempo de compilación. Se desea testar las clases aisladamente sin sus dependencias. Se desea desacoplar sus clases de ser responsables de localizar y gestionar el tiempo de vida de sus dependencias. TÉCNICAS DE IMPLEMENTACIÓN Según diversos enfoques, este patrón puede implementarse de diversas maneras. Entre las más conocidas se tiene: Inyección de dependencias Service Locutor SERVICE LOCATOR Un Service Locator es un componente conteniendo referencias a los servicios y encapsula la lógica localizaando dichos servicios. Así, en las clases, se utilizamo el Service Locator para obtener instancias de los servicios realmente necesarios. El Service Locator no instancia los servicios. Provee una manera de registrar servicios y mantener una referencia a dichos servicios. Una vez registrado el servicio, el Service Locator puede localizarlo. El Service Locator debe proveer una forma de localizar un servicio sin especificar el tipo. Por ejemplo, puede usar una clave string o el tipo de interface. Esto permite un fácil reemplazo de la dependencia sin modificar el código fuente de la clase. Es asunto de la implementación de esta forma de IoC, el determinar la forma en que se localizará el servicio requerido. INYECCIÓN DE DEPENDENCIAS Una dependencia entre un componente y otro, puede establecerse estáticamente o en tiempo de compilación, o bien, dinámicamente o en tiempo de ejecución. Es en éste ultimo escenario es donde cabe el concepto de inyección, y para que esto fuera posible, se deben referenciar interfaces y no implementaciones directas. Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 12

En general, las dependencias son expresadas en términos de interfaces en lugar de clases concretas. Esto permite un rápido reemplazo de las implementaciones dependientes sin modificar el código fuente de la clase. La Inyección de dependencias propone, no instanciar las dependencias explícitamente en su clase, sino que declarativamente expresarlas en la definición de la clase. La esencia de la inyección de las dependencias es contar con un componente capaz de obtener instancias validas de las dependencias del objeto y pasárselas durante la creación o inicialización del objeto. 1. A necesita una referencia a B, pero no necesita saber como debe crear la instancia de B, solo quiere una referencia a ella. 2. B puede ser una interface, clase abstracta o clase concreta. 3. Antes de que una instancia de A sea usada, necesitara una referencia a una instancia de B. Aquí no hay un alto acoplamiento entre A y B, ambas pueden cambiar internamente sin afectar a la otra. Los detalles de cómo se crea y gestiona un objeto B, no es decidido en la implementación de A. Es un framework IoC quien usa un método como setb() de A para inyectar luego a un objeto B. Existen tres principales maneras de implementar la inyección de dependencias: INYECCIÓN BASADA EN CONSTRUCTOR Las dependencias se inyectan utilizando un constructor con parámetros del objeto dependiente. Éste constructor recibe las dependencias como parámetros y las establece en los atributos del objeto. Considerando un diseño de dos capas donde se tiene una capa de BusinessFacade y otra de BusinessLogic, la capa BusinessFacade depende de la BusinessLogic para operar correctamente. Todas las clases de lógica de negocio implementan la interface IBusinessLogic. En la inyección basada en un constructor, se creará una instancia de BusinessFacade usando un constructor parametizado al cual se le pasará una referencia de un IBusinessLogic para poder inyectar la dependencia. interface IBusinessLogic { //Some code class ProductBL implements IBusinessLogic { //Some code class CustomerBL implements IBusinessLogic { //Some code public class BusinessFacade Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 13

{ private IBusinessLogic businesslogic; public BusinessFacade(IBusinessLogic businesslogic) { this.businesslogic = businesslogic; El objeto responsable de las dependencias realizará la inyección de la siguiente forma: IBusinessLogic productbl = new ProductBL(); BusinessFacade businessfacade = new BusinessFacade(productBL); La principal desventaja de la IoC basada en constructor es que una vez que la clase BusinessFacade es instanciada no podemos cambiar las dependencias inyectadas. INYECCIÓN BASADA EN MÉTODOS SETTERS En este tipo de IoC, se utiliza un método setters para inyectar una dependencia en el objeto que la requiere. Se invoca así al setter de cada dependencia y se le pasa como parámetro una referencia a la misma. public class BusinessFacade { private IBusinessLogic businesslogic; public setbusinesslogic(ibusinesslogic businesslogic) { this.businesslogic = businesslogic; El objeto responsable de las dependencias realizará la inyección de la siguiente forma: IBusinessLogic productbl = new ProductBL(); BusinessFacade businessfacade = new BusinessFacade(); businessfacade.setbusinesslogic(productbl); La ventaja aquí es que uno puede cambiar la dependencia entre BusinessFacade y la implementación de IBusinessLogic luego de haber instanciado la clase BusinessFacade. La desventaja es que un objeto con setters no puede ser inmutable y suele ser complicado determinar cuales son las dependencias que se necesitan y en que momento se las necesita. Se recomienda así utilizar IoC basada en constructor a menos que necesite cambiar la dependencia y sepa claramente los momentos en los cuales realizar estos cambios. Otra desventaja es que al utilizar setters (necesarios para la inyección), es la exposición de las propiedades de un objeto al mundo exterior cuando en realidad no era un requerimiento de negocio hacerlo. INYECCIÓN BASADA EN INTERFACES Aquí se utiliza una interfaz común que otras clases implementan para poderles luego inyectar dependencias. En el siguiente ejemplo, a toda clase que implemente IBusinessFacade se le podrá inyectar cualquier objeto que implemente IBusinessLogic mediante el método injectblobject. interface IBusinessLogic { //Some code interface IBusinessFacade { public void injectblobject (IBusinessLogic businesslogic); class ProductBL implements IBusinessLogic { //Some code Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 14

class CustomerBL implements IBusinessLogic { //Some code class BusinessFacade implements IBusinessFacade { private IBusinessLogic businesslogic; public void injectblobject (IBusinessLogic businesslogic) { this.businesslogic = businesslogic; El objeto responsable de las dependencias realizará la inyección de la siguiente forma: IBusinessLogic businesslogic = new ProductBL(); BusinessFacade businessfacade = new BusinessFacade(); businessfacade.injectblobject(businesslogic); Las tres formas de inyección presentadas, pasan una referencia a una implementación de IBusinessLogic más que un tipo particular de BusinessLogic. Esto presenta muchas ventajas. APLICABILIDAD CUANDO UTILIZAR IOC La inyección de dependencias no debería usarse siempre que una clase dependa de otra, sino más bien es efectiva en situaciones específicas como las siguientes: Inyectar datos de configuración en un componente. Inyectar la misma dependencia en varios componentes. Inyectar diferentes implementaciones de la misma dependencia. Inyectar la misma implementación en varias configuraciones Se necesitan alguno de los servicios provistos por un contenedor. La IoC no es necesaria si uno va a utilizar siempre la misma implementación de una dependencia o la misma configuración, o al menos, no reportará grandes beneficios en estos casos. Contenedores En pos de implementar el patrón IoC en alguna de sus variantes, existen los denominados contenedores de inyección de dependencias (CID), que son los componentes encargados de instanciar las dependencias y realizar las inyecciones necesarias entre todos los objetos y además gestionar sus respectivos ciclos de vida. En cuanto a la instanciación e inyección, un CID se configura para especificarle que dependencias debe instanciar y donde deberá luego inyectarlas. Para la instanciación además, se debe definir el modo de instanciación, es decir, si se creará una nueva siempre que se lo requiera, o se reusará la instancia creada (singleton). En cuanto a la gestión de los ciclos de vida de los objetos creados, implica que son capaces de administrar las diferentes etapas de la vida del componente (instanciación, configuración, eliminación). El hecho de que el contenedor a veces mantenga una referencia a los componentes creados luego de la instanciación es lo que lo hace un contenedor. No todos los objetos deben ser gestionados. El contenedor mantiene una referencia a aquellos objetos que son reusados para futuras inyecciones, como singletones. Cuando se configure el contenedor para que siempre cree nuevas instancias, entonces éste se suele olvidar de dichos objetos creados, dejando la tarea al GC para recolectarlos luego de que no sean más usados. Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 15

L11 DESARROLLO DE UNA APLICACIÓN Y CONFIGURACIÓN DEL AMBIENTE: INDEX.JSP, TOMCAT, WEB.XML PASO 1. CREAR LA ESTRUCTURA DEL DIRECTORIO DE PROYECTOS Es recomendable utilizar un directorio donde se almacenen todos los fuentes y los otros archives relacionados con el proyecto. Por ejemplo, en caso de existir una aplicación con el nombre 'springapp', la ruta debería tener la forma de '$HOME/Projects/springapp'. Dentro de este directorio, se crea un sub directorio llamado 'src' para almacenar todos los archivos de código fuente Java. Luego, se crea otro subdirectorio llamado 'war'. Este directorio contiene toda la información a colocar en el archivo.war utilizada para empaquetar e implementar la aplicación. A continuación se muestra un ejemplo de la estructura desarrollada en el IDE de Eclipse. PASO 2 CREAR EL ARCHIVO 'INDEX.JSP' Para desarrollar una aplicación WEB, lo más conveniente es tener una página principal de la herramienta index.jsp en el directorio war. 'springapp/war/index.jsp': <html> <head><title>example :: Spring Application</title></head> <body> <h1>example - Spring Application</h1> <p>this is my test.</p> </body> </html> Para completar una aplicación web, se crea un directorio 'WEB-INF' dentro del directorio 'war' directory y se coloca un archivo 'web.xml' en este directorio: Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 16

'springapp/war/web-inf/web.xml': <?xml version="1.0" encoding="utf-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" > <welcome-file-list> <welcome-file> index.jsp </welcome-file> </welcome-file-list> </web-app> PASO 3 IMPLEMENTAR EN TOMCAT A continuación se muestra un script (ant build) a utilizar en este manual. El script (ant build) contiene las instrucciones para compilar, construir e implementar la aplicación. 'springapp/build.xml': <?xml version="1.0"?> <project name="springapp" basedir="." default="usage"> <property file="build.properties"/> <property name="src.dir" value="src"/> <property name="web.dir" value="war"/> <property name="build.dir" value="${web.dir/web-inf/classes"/> <property name="name" value="springapp"/> <path id="master-classpath"> <fileset dir="${web.dir/web-inf/lib"> <include name="*.jar"/> </fileset>    <fileset dir="${appserver.lib"> <include name="servlet*.jar"/> </fileset> <pathelement path="${build.dir"/> </path> <target name="usage"> <echo message=""/> <echo message="${name build file"/> <echo message="-----------------------------------"/> <echo message=""/> <echo message="available targets are:"/> <echo message=""/> <echo message="build --> Build the application"/> <echo message="deploy --> Deploy application as directory"/> <echo message="deploywar --> Deploy application as a WAR file"/> <echo message="install --> Install application in Tomcat"/> <echo message="reload --> Reload application in Tomcat"/> <echo message="start --> Start Tomcat application"/> <echo message="stop --> Stop Tomcat application"/> <echo message="list --> List Tomcat applications"/> <echo message=""/> <target name="build" description="compile main source tree java files"> Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 17

<mkdir dir="${build.dir"/> <javac destdir="${build.dir" source="1.5" target="1.5" debug="true" deprecation="false" optimize="false" failonerror="true"> <src path="${src.dir"/> <classpath refid="master-classpath"/> </javac> <target name="deploy" depends="build" description="deploy application"> <copy todir="${deploy.path/${name" preservelastmodified="true"> <fileset dir="${web.dir"> <include name="**/*.*"/> </fileset> </copy> <target name="deploywar" depends="build" description="deploy application as a WAR file"> <war destfile="${name.war" webxml="${web.dir/web-inf/web.xml"> <fileset dir="${web.dir"> <include name="**/*.*"/> </fileset> </war> <copy todir="${deploy.path" preservelastmodified="true"> <fileset dir="."> <include name="*.war"/> </fileset> </copy>    <path id="catalina-ant-classpath">   <fileset dir="${appserver.lib"> <include name="catalina-ant.jar"/> </fileset> </path> <taskdef name="install" classname="org.apache.catalina.ant.installtask"> <classpath refid="catalina-ant-classpath"/> </taskdef> <taskdef name="reload" classname="org.apache.catalina.ant.reloadtask"> <classpath refid="catalina-ant-classpath"/> </taskdef> <taskdef name="list" classname="org.apache.catalina.ant.listtask"> <classpath refid="catalina-ant-classpath"/> </taskdef> <taskdef name="start" classname="org.apache.catalina.ant.starttask"> <classpath refid="catalina-ant-classpath"/> </taskdef> <taskdef name="stop" classname="org.apache.catalina.ant.stoptask"> <classpath refid="catalina-ant-classpath"/> </taskdef> <target name="install" description="install application in Tomcat"> <install url="${tomcat.manager.url" username="${tomcat.manager.username" password="${tomcat.manager.password" path="/${name" war="${name"/> <target name="reload" description="reload application in Tomcat"> Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 18

<reload url="${tomcat.manager.url" username="${tomcat.manager.username" password="${tomcat.manager.password" path="/${name"/> <target name="start" description="start Tomcat application"> <start url="${tomcat.manager.url" username="${tomcat.manager.username" password="${tomcat.manager.password" path="/${name"/> <target name="stop" description="stop Tomcat application"> <stop url="${tomcat.manager.url" username="${tomcat.manager.username" password="${tomcat.manager.password" path="/${name"/> <target name="list" description="list Tomcat applications"> <list url="${tomcat.manager.url" username="${tomcat.manager.username" password="${tomcat.manager.password"/>  </project> Si se requiere utilizar un servidor de aplicaciones web diferentes, se pueden eliminar las tareas específicas de Tomcat al final del script. El IDE utilizado puede encontrar un número de errores reportados en el archivo build.xml ; estos pueden ser ignorados, el arhivo es correcto. También es necesario crear un archivo 'build.properties', el cual debe ser modificado dependiendo de la instalación del servidor. Este archivo se coloca en el mismo directorio del arhivo 'build.xml'. 'springapp/build.properties': # Ant properties for building the springapp appserver.home=${user.home/apache-tomcat-6.0.14 # for Tomcat 5 use $appserver.home/server/lib # for Tomcat 6 use $appserver.home/lib appserver.lib=${appserver.home/lib deploy.path=${appserver.home/webapps tomcat.manager.url=http://localhost:8080/manager tomcat.manager.username=tomcat tomcat.manager.password=s3cret Para crear un usuario tomcat llamado 'tomcat' con contraseña 's3cret', en el archivo de usuarios tomcat 'appserver.home/conf/tomcat-users.xml' se debe agregar la siguiente entrada de usuario. <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager"/> <user username="tomcat" password="s3cret" roles="manager"/> </tomcat-users> Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 19

Ahora se ejecuta Ant para asegurar todo se está ejecutando correctamente. El directorio actual debe estar en 'springapp'. Ejecutar 'ant'. $ ant Buildfile: build.xml usage: [echo] [echo] springapp build file [echo] ----------------------------------- [echo] [echo] Available targets are: [echo] [echo] build --> Build the application [echo] deploy --> Deploy application as directory [echo] deploywar --> Deploy application as a WAR file [echo] install --> Install application in Tomcat [echo] reload --> Reload application in Tomcat [echo] start --> Start Tomcat application [echo] stop --> Stop Tomcat application [echo] list --> List Tomcat applications [echo] BUILD SUCCESSFUL Total time: 2 seconds El último paso es construir e implementar la aplicación. $ ant deploy Buildfile: build.xml build: [mkdir] Created dir: /Users/trisberg/Projects/springapp/war/WEB-INF/classes deploy: [copy] Copying 2 files to /Users/trisberg/apache-tomcat-5.5.17/webapps/springapp BUILD SUCCESSFUL Total time: 4 seconds PASO 4 REVISAR LA APLICACIÓN TRABAJA Iniciar Tomcat ejecutando '${appserver.home/bin/startup.bat'. Para asegurarse se puede acceder a la aplicación se encuentra la tarea 'list'. $ ant list Buildfile: build.xml list: [list] OK - Listed applications for virtual host localhost [list] /springapp:running:0:springapp [list] /manager:running:0:manager [list] /:running:0:root [list] /docs:running:0:docs [list] /examples:running:0:examples [list] /host-manager:running:0:host-manager BUILD SUCCESSFUL Total time: 3 seconds Ahora, se puede abrir un navegador y desplegar la página de inicio: http://localhost:8080/springapp/index.jsp. Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 20

DESCARGAR EL FRAMEWORK SPRING El framework puede ser descargado de http://www.springframework.org/download. MODIFICAR EL ARCHIVO 'WEB.XML' EN EL DIRECTORIO 'WEB-INF' En el directorio 'springapp/war/web-inf', modificar el archivo 'web.xml'. Se definirá un DispatcherServlet (conocido como 'Front Controller'). Este elemento controlará todos los requerimientos y los enrutará donde se necesite. Esta definición de servlet tiene una entrada attendant <servlet-mapping/> mapeando a los patrones URL patterns utilizados. En los ejemplos aquí mostradod los URL con una extensión '.htm' serán enrutados al servlet 'springapp' (DispatcherServlet). 'springapp/war/web-inf/web.xml': <?xml version="1.0" encoding="utf-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" > <servlet> <servlet-name>springapp</servlet-name> <servlet-class>org.springframework.web.servlet.dispatcherservlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 21

<servlet-mapping> <servlet-name>springapp</servlet-name> <url-pattern>*.htm</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file> index.jsp </welcome-file> </welcome-file-list> </web-app> En el siguiente paso, crear un archivo llamado 'springapp-servlet.xml en el directorio 'springapp/war/web- INF'. Este archivo contiene las definiciones de los bean utilizados por DispatcherServlet. En el objeto WebApplicationContext es donde se colocan todos los componentes web. El nombre de este archivo es determinado por el valor del elemento <servlet-name/> del archivo de configuración 'web.xml', con '-servlet' de sufijo (siendo 'springapp-servlet.xml'). Esta es la convención de nombres standard utilizada en el modelo MVC de Framework Spring. A continuación, se agrega un bean llamado '/hello.htm' y se especifica la clase springapp.web.hellocontroller. Esto define el controlador de la aplicación para servir los requerimientos realizados al URL '/hello.htm'. El framework MVC de Spring utiliza una clase de implementación de la interfaz llamada HandlerMapping para definir el mapeo entre el Url de requerimiento y el objeto manejando el requerimiento (el handler). Distinto a DispatcherServlet, el HelloController es el responsable por manejar el requerimiento para una página el particular del sitio web y es también conocido como un controlador de páginas 'Page Controller'. El HandlerMapping por defecto utilizado por el DispatcherServlet es BeanNameUrlHandlerMapping; esta clase utilizará el nombre del bean para mapear al URL en el requerimiento, de modo que el DispatcherServlet conoce cual controlador debe ser invocado para manear diferentes URLs. 'springapp/war/web-inf/springapp-servlet.xml': <?xml version="1.0" encoding="utf-8"?> <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-2.5.xsd">  <bean name="/hello.htm" class="springapp.web.hellocontroller"/> </beans> COPIAR LAS LIBRERÍAS EN 'WEB-INF/LIB' Crear un directorio 'lib' en el directoorio 'war/web-inf'. Luego, desde la distribución de Spring, copiar spring.jar (desde spring-framework-x.x/dist) y spring-webmvc.jar (desde spring-frameworkx.x/dist/modules) al nuevo directorio 'war/web-inf/lib'. También, copiar commonslogging.jar (desde spring-framework-x.x/lib/jakarta-commons) al directorio 'war/web-inf/lib'. Estos.jars serán implantados al servidor durante el proceso de build. CREAR EL CONTROLADOR Crear la clase controlador. El el ejemplo se denomina HelloController, y es definida en el paquete 'springapp.web'. Se crea el directorio de los paquetes, luego se crea el archivo 'HelloController.java' y se coloca en el directorio 'src/springapp/web'. 'springapp/src/springapp/web/hellocontroller.java': package springapp.web; Copyright 2011 Reservados todos los derechos, prohibida la reproducción, Instituto Gala de Venezuela, C. A. 22