Guía técnica para Desarrollo de aplicaciones JAVA

Página 1 de 21

GUÍA TÉCNICA

Desarrollo de Sistemas de Información con

arquitectura JAVA en el Gobierno de Extremadura

GOBIERNO DE EXTREMADURA

Dirección General de Administración Electrónica y Tecnologías de la Información

GUÍA TÉCNICA

Desarrollo de Sistemas de Información con arquitectura JAVA

Núm Fecha Descripción Autores

2.0 10/02/10 • Se actualiza la plataforma JAVA.• Se realiza una revisión completa del documento “EstandarJAVA.odt”.

SAE – SIS

3,0 01/07/14 • Revisión completa del documento. SDP

Página 2 de 21



GUÍA TÉCNICA


Control de versiones

Capítulo Página

1- Alcance del documento 1

2.- Plataforma JAVA 4

3.- Requisitos que deben cumplir las aplicaciones. 5

3.1.- Comptabilidad de navegadores y Sistemas Operativos 5

3.2.- Independizar a la aplicación de un contexto 6

3.3.- N ejecutar código que afecte al comportamiento de la máquina virtual

7

3.4.- Aprovechar los recursos y liberías que ofrece Jboss 7

3.5.- Tratamiento de procesos pesados en el servidor 8

3.6.- Gestión de documentos mediante Alfresco 9

4.- Bases de datos 9

4.1.- Datasources 9

4.2.- Drivers JDBF 10

4.3.- Persistencia de objetos 11

5.- Gestión de la aplicación 13

5.1.- Apache Maven 3 13

5.2.- Despliegue de aplicaciones JAVA 14

6.- Arquitectura de la aplicación. Frameworks, utilidades y liberías 15

6.1.- Frameworks permitidos 15

6.2.- Spring Framework 17

6.3.-JSF (Java Server Faces) 17

6.4.- Apache CXF 18

6.5.- JasperReports 19

7.- Librerías disponibles en el servidor Jboss 20

7.1.- Librerías incorporadas enel servidor 20

8.- Sistema de log y auditoría de la aplicación 21

Página 3 de 21



GUÍA TÉCNICA


Índice del Documento

Capítulo Página

8.1.- Jboss LogManagger 22

La Dirección General de Administración Electrónica y Tecnologías de la Información especifica en el presente documento las características que deben cumplir las aplicaciones realizadas en JAVA a implantar en la Junta de Extremadura.

Se describe el entorno tecnológico JAVA existente, a tener en cuenta a la hora de implementar aplicaciones compatibles con dicha plataforma.

Otro objetivo es establecer los estándares, frameworks y librerías que deben utilizarse en las aplicaciones a desarrollar, para conseguir que cumpla con unos requisitos mínimos de calidad y estandarización, así como facilitar la tarea de mantenimiento de las aplicaciones.

En principio, todas las aplicaciones web a implementar utilizando JAVA deberán respetar los estándares aquí establecidos. Pero teniendo en cuenta la gran variedad de productos disponibles (frameworks, librerías, entornos, ...) y las características particulares de cada aplicación, podrá utilizarse algún componente, tecnología o herramienta no descrita en este documento, siempre y cuando el la Dirección General de Administración Electrónica y Tecnologías de la Información conozca este hecho y apruebe su uso.

El entorno tecnológico JAVA utilizado como referencia por el Gobierno de Extremadura para el desarrollo de sistemas de información es el siguiente:

• Java Platform, Enterprise Edition 6 (Oracle JDK 1.6)

◦ Es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en lenguaje de programación Java con

Página 4 de 21



GUÍA TÉCNICA


1.- Alcance del documento

2.- Plataforma JAVA

arquitectura de niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones.

◦ http://www.oracle.com/us/technologies/java/enterprise-edition

• JBoss EAP 6

◦ JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo que lo soporte.

◦ Los principales desarrolladores trabajan para una empresa de servicios, JBoss Inc., adquirida por Red Hat. El proyecto está apoyado por una red mundial de colaboradores.

◦ JBoss implementa todo el paquete de servicios de J2EE.

◦ http://www.jboss.org/products/eap/

Las aplicaciones tienen que ser 100% compatibles con esta plataforma.

A continuación se exponen los criterios a seguir en relación a hacer compatibles las aplicaciones y sus entornos de ejecucion:

• Las aplicaciones web deben ser compatibles con los navegadores más

Página 5 de 21



GUÍA TÉCNICA


3.- Requisitos que deben cumplir las aplicaciones

3.1.- Compatibilidad de navegadores y sistemas operativos

utilizados hoy en día. Se exige como mínimo compatibilidad con los navegadores:◦ Internet Explorer◦ Mozilla Firefox◦ Chrome

En todo momento hay que evitar código que pueda provocar problemas de incompatibilidad entre navegadores diferentes e incluso entre diferentes versiones del mismo navegador.

• La aplicación debe ejecutarse correctamente en clientes Windows y clientes Linux.

• La aplicación debe funcionar correctamente independientemente del Sistema Operativo que corra en la máquina servidora, de forma que se pueda migrar el software de base de la maquina servidora sin afectar al funcionamiento del aplicativo. Por lo que se debe evitar cualquier dependencia en el código con un sistema operativo en concreto.

Deberán cumplirse los siguientes criterios:

• Las aplicaciones deberán implementarse y empaquetarse de manera que sea posible desplegar la misma aplicación más de una vez sobre el mismo servidor (con diferente nombre y contexto).

Es frecuente que la misma aplicación sea utilizada por más de un órgano funcinal, por lo que es necesario desplegarla en el mismo servidor con diferente nombre.

Para conseguir esta compatibilidad, los aspectos que hay que tener en cuenta a la hora de desarrollar la aplicación son los siguientes: ◦ Será necesario poder modificar el contexto de la aplicación. Una de las

posibilidades es cambiar el nombre del fichero .war de la aplicación.

Página 6 de 21



GUÍA TÉCNICA


3.2.- Independizar a la aplicación de un contexto

En algunos servidores también es posible definir el contexto de la aplicación en ficheros de configuración (context.xml, jboss-web.xml, ...).

◦ Todas las referencias a URLs y/o recursos de la aplicación deben ser relativas o dinámicas a partir del contexto de la aplicación.

◦ El acceso a BD (datasource utilizado) debe ser parametrizable. Así conseguiremos definir a la BD que accede cada aplicación.

◦ Se deberá parametrizar todo lo posible aquellos parámetros relacionados con la configuración de la aplicación, y que puedan desencadenar problemas en el momento de desplegar más de una aplicación sobre el mismo servidor.

• No puede existir código en las aplicaciones que pueda modificar o cambiar el comportamiento de la máquina virtual de JBoss. Existen algunas instrucciones, tales como System.setProperty(String key, String value) ó System.gc() que tienen efectos sobre la maquina virtual que ejecuta JBoss, y por lo tanto puede tener efectos secundarios sobre el resto de aplicaciones que están corriendo en el servidor.

• Es requisito imprescindible que las aplicaciones aprovechen y usen las librerías proporcionadas por el servidor JBoss.

• Aparte de las librerías que incorpora por defecto JBoss, la Dirección General de Administración Electrónica y Tecnologías de la Información incorporará un conjunto de ellas para que las aplicaciones desplegadas tengan acceso a las mismas.

• Para todo este conjuntos de librerías las aplicaciones tendrán que adaptarse a la versión proporcionada, y en ningún caso podrán

Página 7 de 21



GUÍA TÉCNICA


3.3.- No ejecutar código que afecte al comportamiento de la máquina virtual

3.4.- Aprovechar los recursos y librerías que ofrece el servidor JBoss

incorporar en el WAR librerías ya disponibles o versiones diferentes de las mismas.

• En algunas ocasiones las aplicaciones web requieren la ejecución de procesos que pueden llegar a consumir muchos recursos de máquina (memoria y procesador), y cuya ejecución se puede alargar durante un tiempo no despreciable, como pueden ser:◦ procesos de calculo complejo◦ consultas masivas de datos◦ creación de listados o informes masivos de datos◦ etc..

• La ejecución de estos procesos de forma interactiva suele provocar problemas como:◦ la perdida de timeout de la sesión web◦ problemas con los sistemas de filtrado, seguridad, y/o balanceo de

carga que puedan existir en la interconexión entre el cliente y el servidor.

◦ penalización del rendimiento del servidor Java, y en consecuencia penalización del rendimiento de las aplicaciones desplegadas.

• Si la aplicación requiere de la ejecución de algún proceso con estas características, es necesario que ofrezca al usuario una forma alternativa de ejecución que no ocasione los problemas anteriormente mencionados, y lance el proceso en “segundo plano”, e incluso en su caso pudiese derivarlo a otro servidor que llevaría a cabo el proceso.

A su vez deberá implementarse un “proceso de notificación”, de forma que cuando el proceso haya finalizado se le comunique al usuario de alguna forma. En ese momento el usuario de la aplicación podrá acceder o consultar los resultados de la ejecución del proceso.

Página 8 de 21



GUÍA TÉCNICA


3.5.- Tratamiento de procesos pesados en el servidor

• Las aplicaciones que requieran de la gestión de documentos deberán trabajar con el gestor de contenidos Alfresco.

• La Dirección General de Administración Electrónica y Tecnologías de la Información proporcionará la documentación necesaria para la interacción con Alfresco mediante servicios web.

• Todo acceso a BD se deberá hacer mediante la configuración de un datasource a BD en el servidor JBoss (ficheros –ds.xml). No se permite el acceso a bases de datos que no sea a través del datasource correspondiente configurado en el servidor JBoss.

El nombre del datasource (jndi-name) a su vez vendrá parametrizado en la aplicación.

Opciones de parametrización:• parámetro de contexto del fichero web.xml• fichero de propiedades de la aplicación• fichero de configuración de la aplicación• campo de base de datos

Ejemplo de fichero web.xml:…<context-param>

Página 9 de 21



GUÍA TÉCNICA


3.6.- Gestión de documentos mediante Alfresco

4.- Bases de datos

4.1.- Datasources

<param-name>datasource</param-name><param-value>java:/jdbc/sqlserver/dbPruebas</param-value>

</context-param>…

• Mediante esta configuración JBoss proporciona un pool de conexiones parametrizable y configurable “en caliente”, que permite modificar los parámetros del pool y de las conexiones a la BD sin necesidad de reiniciar el servidor o desplegar de nuevo la aplicación.

Debido a que esta funcionalidad ya la proporciona el servidor, las aplicaciones no deberán implementar ningún mecanismo de pool o caché de conexiones.

Siguiendo estas pautas, la actualización del fichero -ds.xml, donde están definidos los pool de conexiones, no debe ocasionar problemas en las aplicaciones.

Los drivers JDBC utilizados para acceder a las BD se encuentran en el classpath del servidor (JBOSS_HOME/server/default/lib), por lo que éstos nunca se integrarán en el desplegable de la aplicación (fichero .war de la aplicación).

A continuación se indican los sistemas gestores de bases de datos permitidos y los drivers JDBC respectivos instalados en el servidor JBoss:

Microsoft SQL Server

• Microsoft sql server jdbc driver 2.0 (sqljdbc4.jar)◦ Driver de Microsoft que permite a las aplicaciones Java, acceder a las

bases de datos Microsoft SQL Server 2000, Microsoft SQL Server 2005 y Microsoft SQL Server 2008 a través de JDBC (Java Database Connectivity).

◦ http://www.microsoft.com/downloads/

Página 10 de 21



GUÍA TÉCNICA


4.2.- Drivers JDBC

http://www.microsoft.com/downloads/

PostgreSQL

• PostgreSQL JDBC Driver (postgresql-8.4-701.jdbc4.jar)

◦ Driver JDBC 4 de PostgreSQL. ◦ http://jdbc.postgresql.org/

MySQL

• MySQL Connector/J 5.1 (mysql-connector-java-5.1.11-bin.jar)◦ El MySQL Connector/J es un driver JDBC 4 y contiene todas las

características de JDBC para manejar Mysql.◦ http://dev.mysql.com/downloads/connector/j/

ORACLE

• ORACLE JDBC driver (ojdb6.jar)

◦ El driver JDBC 4 para ORACLE, contiene todas las características de JDBC para manejar ORACLE.

◦ http://www.oracle.com/technetwork/database/features/jdbc

Para la persistencia de objetos en BD relacionales deberá utilizarse alguna de las siguientes dos opciones:

• JPA (versión 2.0)◦ Java Persistence API (JPA) proporciona un estándar para gestionar

datos relacionales en aplicaciones Java SE o Java EE, de forma que

Página 11 de 21



GUÍA TÉCNICA


4.3.- Persistencia de objetos

Hibernate (JPA)

http://dev.mysql.com/downloads/connector/j/

http://jdbc.postgresql.org/

además se simplifique el desarrollo de la persistencia de datos.◦ Aunque ha sido definida como parte de la especificación EJB 3.0 (Java

EE 5), que supone una simplificación sobre versiones anteriores, ya no requiere de un contenedor EJB ni un servidor de aplicaciones Java EE.

Es una API de persistencia de POJOs (Plain Old Java Object). Es decir, objetos simples que no heredan ni implementan otras clases (como los EJBs).

◦ http://java.sun.com/javaee/technologies/persistence.jsp

• Hibernate (versión 4.2.14)◦ Hibernate es una herramienta de Mapeo objeto-relacional ORM para la

plataforma Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación.

◦ Hibernate es software libre, distribuido bajo los términos de la LGPL (Licencia Pública General Menor de GNU).

◦ http://www.hibernate.org/

• Hibernate está certificada mediante el Sun Technology Compatibility Kit (TCK) como compatible con la especificación Java Persistence API (JPA).

• Preferiblemente se utilizará esta opción, Hibernate con anotaciones JPA, para implementar la persistencia de los objetos en bases de datos relaciones.◦◦◦

Como alternativa a Hibernate, se podrá usar MyBatis. Es una herramienta de persistencia Java que se encarga de mapear sentencias SQL y procedimientos almacenados con objetos a partir de ficheros XML o anotaciones.

A diferencia de las herramientas ORM, MyBatis no mapea objetos Java a tablas de base de datos sino métodos a sentencias SQL.

No se permitirá el uso de SQL directamente. Si es necesario utilizar

Página 12 de 21



GUÍA TÉCNICA


Maybatis (Versión 3.2.7)

http://www.hibernate.org/

http://java.sun.com/javaee/technologies/persistence.jsp

sentencias SQL se hará utilizando este framework. De esta forma podrá migrarse fácilmente la BD a otro SGBD sin afectar al funcionamiento de la aplicación.

Preferiblemente las sentencias SQL y el mapeo de los objetos se definirá en ficheros xml en lugar de utilizar anotaciones.

Para la gestión del proyecto Java se utilizará la herramienta Apache Maven 3.

• Apache Maven es un software para la gestión de proyectos. Es similar en funcionalidad a Apache Ant, pero tiene un modelo de configuración de construcción más simple, basado en un formato XML.

• Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externo, y el orden de construcción de los elementos.

• Una característica clave de Maven es que está listo para usar en red. El motor incluido en su núcleo puede dinámicamente descargar plugins de un repositorio, el mismo repositorio que provee acceso a muchas versiones de diferentes proyectos Open Source en Java, de Apache y otras organizaciones y desarrolladores.

• http://maven.apache.org/

Página 13 de 21



GUÍA TÉCNICA


5.- Gestión de la aplicación

5.1.- Apache Maven 3

http://maven.apache.org/

• Todas las aplicaciones web JAVA deberán desplegarse en el servidor como un fichero WAR (Web ARchive).

Las librerías (ficheros .jar) que forman parte de la aplicación deben integrarse en el fichero .war de la aplicación (carpeta web/WEB-INF/lib).

Ninguna librería especifica de la aplicación se desplegará en la carpeta de librerías compartidas del Servidor JBoss (JBOSS_HOME/server/default/lib).

• Como ya se ha indicado en este documento siempre se deberán aprovechar y utilizar las librerías y recursos que dispone el servidor JBoss para las aplicaciones. De esta forma se optimizan los recursos en el servidor y se reduce el tamaño final del fichero .war.

• El fichero de gestión del proyecto de Maven deberá gestionar correctamente esta situación, es decir, el caso de la dependencia de la aplicación de ciertas librerías para la compilación del proyecto, pero que no son necesarias en el despliegue de la aplicación, ya que se encuentran en el classpath del servidor.

• Cualquier incorporación de librerías ya disponibles en JBoss en el .war de la aplicación deberá ser justificado y aceptado por la Dirección General de Administración Electrónica y Tecnologías de la Información.

Página 14 de 21



GUÍA TÉCNICA


5.2.- Despliegue de aplicaciones web JAVA

En la elección de los frameworks partimos del marco de trabajo que ofrece Spring y para cada capa definimos distintas alternativas que siempre se deben utilizar integradas con el mismo.

En este contexto los frameworks de soporte a la arquitectura que serán válidos son los siguientes:

Página 15 de 21

JSF

POJO EJB

HibernateMyBatis

CA

PA D

E PR

ESEN

TAC

IÓN

Struts2Spring MVC

CA

PA D

E N

EGO

CIO

CA

PA D

E N

EGO

CIO

Sprin

g



GUÍA TÉCNICA


6.- Arquitectura de la aplicación. Frameworks, utilidades y librerías

6.1.- Frameworks permitidos

Respecto a ello, se hacen las siguientes consideraciones:

• Capa de presentación: para esta capa son válidos los frameworks Struts2 y Spring MVC así como las implementaciones de JSF Mojarra y MyFaces. En cuanto a las extensiones de JSF son válidas cualquiera de las existentes (IceFaces, RichFaces, …).

• Capa de negocio: preferentemente se utilizarán POJOs. Los EJBs estarán permitidos únicamente cuando que exista un condicionante (rendimiento, memoria, …) que así lo aconseje. En este caso se debe justificar su uso.

• Capa de acceso a datos: preferentemente se utilizará las implementación de JPA Hibernate. También se puede utilizar MyBatis si la complejidad de la base de datos a utilizar así lo aconseja. En cualquier caso no se permitirá el acceso directos a bases de datos (JDBC), siempre se realizará dicho acceso a través de uno de estos frameworks.

La elección de una alternativa en cualquiera de las capas no condiciona la elección en cualquiera de las otras capas, de forma que serán consideradas válidas las arquitecturas constituidas por cualquiera de las combinaciones posibles.

Si se cree conveniente utilizar un framework que no se encuentre entre los propuestos su uso queda supeditado a la autorización previa del mismo por parte de la dirección del proyecto.

Para cualquier framework que se necesite fuera de las capas aquí señaladas siempre se preferirá la alternativa ofrecida por Spring (SpringWS para los servicios web, Spring Security para la gestión de la seguridad, …). En caso de que no exista una alternativa dentro de Spring se preferirán los frameworks más utilizados para esa tarea en concreto (Quartz para tareas,...). En cualquier caso la inclusión de cualquier de estos frameworks se consultará previamente con la dirección del proyecto.

A efectos de facilitar y coordinar las implantaciones de aplicativos en los Sistemas de la Junta de Extremadura, se proporcionará una plataforma basada en los servidores Tomcat o Jboss con las librerías ya instaladas en los mismos. Esto supone que las aplicaciones a implantar no deberán incluir ninguna librería ni componente de los que ya provea la administración, salvo motivos debidamente justificados.

Página 16 de 21



GUÍA TÉCNICA


Spring es un framework para aplicaciones Java que proporciona facilidad de crear componentes reutilizables, adaptándose fácilmente con otros frameworks como Hibernate, JSF, Apache CXF, etc.

El principio en el que se basa este framework es “Dependency Injection”.

Se integrará en el servidor JBoss las librerías (ficheros .jar) que forman el núcleo de este framework.(ttp://www.springframework.org/ )

• La tecnología JavaServer Faces (JSF) es un marco de trabajo para interfaces de usuario para aplicaciones J2EE. Por diseño, es particularmente útil con aplicaciones basadas en la arquitectura MVC.

• JBoss incorpora la implementación (“Proyect Mojarra”) de la especificación JSF 1.2. , por lo que no es necesario añadir la implementación de JSF directamente en el WAR.

• http://java.sun.com/javaee/javaserverfaces/ • http://community.jboss.org/wiki/JBossWithJSFCDDL

◦◦◦

• Se propone RichFaces como librería de componentes visuales JSF.• RichFaces es una librería de componentes visuales para JSF, que además

posee un framework avanzado para la integración de funcionalidades Ajax en dichos componentes visuales, mediante el soporte de la librería Ajax4JSF.

Página 17 de 21



GUÍA TÉCNICA


6.2.- Spring Framework (versión 3.2.9)

6.3.- JSF (Java Server Faces) (versión 1.2)

6.3.1.- RichFaces (versión 3.3.3)

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=Ajax4Jsf

http://community.jboss.org/wiki/JBossWithJSFCDDL

http://java.sun.com/javaee/javaserverfaces/

http://www.springframework.org/

• El uso de otra librería JSF deberá ser aceptada por la Dirección General de Administración Electrónica y Tecnologías de la Información.

• http://www.jboss.org/richfaces

Apache CXF es un framework de servicios de Software Libre. CXF nos ayuda a construir y desarrollar servicios usando JAXWS y JAXRS como API de programación. Estos servicios pueden comunicarse a través de una gran variedad de protocolos como como SOAP, XML/HTTP, HTTP RESTful, o CORBA, y puede trabajar sobre transportes como HTTP, JMS o JBI.

Las características principales de CXF son:

• Soporte para estándares de Servicios Web: CXF soporta varios estándares de servicios web incluyendo a SOAP, el Perfil Básico, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging y WS-Security.

• Interfaces: CXF soporta varios modelos de programación como "interfaz". CXF implementa el API JAX-WS. También incluye una "interfaz simple" que permite crear clientes y endpoints sin utilizar anotaciones. CXF soporta el desarrollo por “contrato primero” con WSDL, y el desarrollo por “código primero” comenzando desde Java.

• Facilidad de uso: CXF está diseñado para ser intuitivo y fácil de usar. Hay APIs simples para construir servicios comenzando por el código, plugins de Maven para integrar esta herramienta, soporte para el API JAX-WS, soporte de XML de Spring para facilitar la configuración, etc.

• Soporte para protocolos binarios y legacy: CXF fue diseñado para proveer una arquitectura extensible que no sólo soporte XML sino también otros binding no XML, como JSON y CORBA, en combinación con cualquier tipo de transporte.

• Un punto muy importante a tener en cuenta de Apache CXF es su facilidad para la integración con Spring.

Página 18 de 21



GUÍA TÉCNICA


6.4.- Apache CXF (Versión 2.6)

http://www.jboss.org/richfaces

• http://cxf.apache.org/

• JasperReports es una herramienta de código libre en Java para generar reportes. Puede generar presentaciones o diseños en la pantalla, para la impresora o para archivos en formato PDF, HTML, RTF, XLS, CSV y XML. Está escrita en Java y se puede utilizar en una gran variedad de aplicaciones Java, incluyendo J2EE o aplicaciones Web.

• http://www.jasperforge.org/

• Es recomendable utilizar la herramienta iReport que es un editor gráfico que está implementado en java y se integra perfectamente con el JasperReport.

• http://jasperforge.org/plugins/project/project_home.php? projectname=ireport

• Otra ventaja de utilizar JasperReport es que se integra perfectamente con el JfreeChart que es una librería libre para la generación de todo tipo de gráficos.

• http://www.jfree.org/jfreechart/

Página 19 de 21



GUÍA TÉCNICA


6.5.- JasperReport

http://www.jfree.org/jfreechart/

http://jasperforge.org/plugins/project/project_home.php?projectname=ireport

http://jasperforge.org/plugins/project/project_home.php?projectname=ireport

http://www.jasperforge.org/

http://cxf.apache.org/

Las aplicaciones deberán usar cuando así lo requieran las librerías que por defecto ofrece JBoss, así como las librerías que se han añadido posteriormente al servidor para que estén disponibles para todas las aplicaciones. Las aplicaciones no deberán incorporar en su WAR las librerías (o una versión diferente de las mismas) que se encuentran en la instalación de JBoss y las que se han añadido por la Dirección General de Administración Electrónica y Tecnologías de la Información.

El siguiente conjunto de librerías o frameworks se han añadido al servidor (JBOSS_HOME/server/default/lib/) para que estén disponibles para todas las aplicaciones desplegadas. Las aplicaciones deberán adaptarse a la versión especificada.

• JDBC drivers

• Spring 3.2.9

Página 20 de 21



GUÍA TÉCNICA


7.- Librerías disponibles en el servidor JBoss

7.1- Librerías incorporadas al servidor

Para el sistema de log de la aplicación se utilizará la viene incluida con Jboss y que está activada por defecto.

• Este sistema es completamente configurable en tiempo de ejecución utilizando archivos externos de configuración.

• https://docs.jboss.org/author/display/AS71/Logging+Configuration

En el código se utilizará la clase org.jboss.logging.Logger.

Las aplicaciones no tienen la necesidad de incorporar en los ficheros .war la librería, ya que ésta se encuentra en JBOSS_HOME/modules/system/layers/base/org/jboss/logmanager.

Página 21 de 21



GUÍA TÉCNICA


8.- Sistema de log y auditoría de la aplicación

8.1- Jboss LogManagger

Documents

Guía técnica para Desarrollo de aplicaciones JAVA