THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Este artículo será una introducción para entender al plan de activación Geronimo para el usuario en diversas áreas de desarrollo de aplicaciones Web. Como el plan de activación Geronimo es un amplio tema, a futuro se buscará cubrir a mayor grado. El artículo describirá la estructura del plan geronimo-web.xml y sus elementos a detalle, así como indicar cómo se organiza para señalar a diversos recursos. Para proporcionar gran cantidad de información sobre los planes de activación web de geronimo, se inicia con un ejemplo simple Holamundo y se continua al discutir sobre planes de activación web geronimo de aplicaciones web ejemplo existentes.
Este artículo se organiza en las secciones siguientes : -
1.0 Descripción del plan de activación web geronimo
El plan de activación Geronimo para una aplicación Web, es un documento XML. Se define por el esquema geronimo-web-1.1.xsd. el cual puede encontrarse en el subdirectorio <geronimo_home>/schema/ del directorio principal de instalación de Geronimo. Este plan de activación debería encontrarse en la carpeta WEB-INF y ser llamado geronimo-web.xml e incluido en el WAR de la aplicación Web.
El plan de activación siempre debería emplear el namespace web Geronimo, y típicamente requiere elementos del Geronimo Naming namespace. Además, tiene un atributo requerido para identificar su nombre de configuración, así como un atributo opcional para seleccionar una configuración padre. Un plan de activación de aplicación Web típica incluirá los atributos siguientes y debería encontrarse en la carpeta WEB-INF:
geronimo-web.xml
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1" xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1" xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1" xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1"> ... </web-app>
Descripción del contenido del código superior :
- Esquema Geronimo para los planes del servidor y elementos comunes (http://geronimo.apache.org/xml/ns/deployment-1.1), se usa para activar (deploy) nuevos servicios en Geronimo en un plan standalone, y también contiene elementos comunes usados por muchos otros planes.
- Los elementos sin prefijo son del namespace http://geronimo.apache.org/xml/ns/j2ee/web-1.1, mientras que los elementos con el prefijo naming: son del namespace http://geronimo.apache.org/xml/ns/naming-1.1 y los elementos con el prefijo sys: son del namespace http://geronimo.apache.org/xml/ns/deployment-1.1. Los tres namespaces son identificados en el encabezado web-app (el cual los hace disponibles en cualquier lugar dentro del documento).
- Si se emplea la versión Jetty de Geronimo, entonces el namespace del servidor puede ser usado como http://geronimo.apache.org/xml/ns/j2ee/jetty-1.1, mientras que si es Tomcat entonces puede ser usado como http://geronimo.apache.org/xml/ns/j2ee/tomcat-1.1. Por lo tanto, el uso común del namespace objetivo (target) de una aplicación Web en Geronimo es http://geronimo.apache.org/xml/ns/j2ee/web-1.1.
- ModuleID y dependencias se definen en el bloque <environment> del archivo XML. Cualquier aplicación ó módulo puede declarar un moduleID para si misma(o) mediante el elemento moduleID, y puede declarar dependencias mediante el elemento dependency. El siguiente ejemplo detalla dependencias declaradas en el bloque <environment>.
Porción de la aplicación ejemplo
<environment
xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.1">
<moduleId>
<groupId>geronimo</groupId>
<artifactId>HolaMundo</artifactId>
<version>1.1</version>
<type>war</type>
</moduleId>
</environment>
Al activar la aplicación, HolaMundo.war será creado en la carpeta <geronimo_home>/deploy/.
Para accesar al ejemplo activo, se requiere entrar a la dirección url. Consulta 1.1.3 Aplicación web: Raíz de Contexto para mayor detalle.
1.1 Perspectiva del plan de activación de aplicación web
Existe una estructura interna para el plan de activación Web de Geronimo; es decir, el plan de activación Web sigue una estructura específica y orden de elementos.
1.1.1 Identificación de aplicación web y Ruta de activación
La Herramienta de Activación y la consola se refieren a una aplicación Web mediante el nombre definido en moduleID y los elementos de plan de activación configuran su classpath.
1.1.2 Aplicación web: Ruta de activación
Estos elementos son:
ModuleId : Un moduleID unifica al módulo específico; incluyendo su nombre, versión, etc. De hecho, existen cuatro componentes de un moduleID. El moduleID crea un nombre único para la aplicación Web. Si moduleID no se proporciona, el nombre de la aplicación Web será default/nombre-del-war/timestamp/war.
Dependencies : Lista de dependencias del módulo. Cada dependencia puede ser otro módulo (como un módulo EJB ó un pool de base de datos), ó una librería ubicada en las dependencias en el repositorio Geronimo. También mantiene la información de identificación para una dependencia particular. Sólo se requiere artifactID, aunque la dependencia debería ser lo suficientemente específica para identificar al JAR ó módulo – es conveniente identificar a detalle las dependencias y evitar el uso de identificación aleatoria (ver GroupID).
GroupID: Nombre de identificación de un grupo de módulos relacionados. Este puede ser el nombre de un proyecto, compañía, etc. Lo importante es que cada artifactID debería ser único en el grupo. Si no se especifica al grupo cuando se declara un moduleID para un módulo ó aplicación, entonces se asigna el ID grupo default. Si no se especifica el grupo para un moduleID empleado para identificar una dependencia, entonces se le trata como un número aleatorio y el grupo no se usa para identificar con exactitud a la dependencia.
ArtifactID: Nombre de identificación para un módulo específico dentro del grupo. Por ejemplo, podría existir un group ID para una aplicación, con artifact IDs separados para la aplicación Web y módulos EJBs que creen la aplicación. Cada moduleID debe incluir un artifactID explícito. Si no se especifica moduleID al activar un módulo, artifactID detalla nombres de archivo para el nombre del módulo.
------> FALTA TRADUCCION
Version : Each module has a version number. If the version number is specified when decaring the moduleID for a module or application, it will get the numeric timestamp as it's version number. Each time the module is redeployed it will get a new timestamp. If no version number is specified for a moduleID used to identify a dependency, then any available version will be used. If there are multiple versions, Geronimo favors any version that might already be loaded, or else typically the newest version will be used.
Type : A module's type is normally either CAR (for a system module) or the file extension for an application module (ear,war,jar,etc). If no type is specified, the type will be set appropriately by the deployer when the module is deployed.
Import : Used for dependencies. For a dependency that's a JAR, this is not useful and should just be omitted. For a dependency that's a separate Geronimo module, there are three possibilities. One, the class loader for the module should be added as a parent of the class loader for the Web application (this might be used if the module is just an aggregation of common JARs). For that behavior, set this value to classes. The second option is that the services defined in the module should be started before and available to this module (this might be used for a database pool where the classes are not needed but the pool must be started). For that behavior, set this value to services. If this element is not included, you get both (the module is on the class path and the services are started first). Under most circumstances this element should be omitted and the default behavior will be correct.
Hidden-classes : Lists packages or classes that may be in a parent class loader, but should not be exposed from there to the Web application. This is typically used when the Web application wants to use a different version of a library than that of it's parent configuration (or Geronimo itself) uses.
Non-overridable-classes : Lists packages or classes that the Web application should always load from a parent class loader, and never load from WEB-INF/lib or WEB-INF/classes. This might be used to force a Web application to share the same instance of a common library with other Web applications, even if they each include it in their own WAR.
filter classes or packages : The format is a list of packages seperated by commas or fully-qualified class names (for example: javax.servlet,javax.ejb).
inverse-classloading : Normally (if this element is omitted), the module's class loader will work normally – classes will be loaded from the parent class loader if available before checking the current class loader. If this element is added, that behavior is reversed and the current class loader will always be checked first before looking in the parent class loader. This is often enabled to give the JARs in WEB-INF/lib precedence over anything that might be in a parent class loader. This element does not take any content, it is simply present or absent.
Suppress-default-environment : This should not be used for Web applications.
1.1.3 Web application: context root
This element controls the URL that clients use to access the Web application.
Context-root :
The context root is the first segment of the URL used to access the Web application by the client. For example, if the context-root was hello, then a typical URL to the application would start with http://host:port/hello/ and a context-root value of / would be used to make this the default Web application for the server.
1.1.4 Web Application: Binding to Specific Ports
A Web application is normally deployed to the default Web container instance, and uses the network ports for that Web container. But it's possible to set up an additional Web container with different network ports and other configuration settings. The web-container element can be used to associate this Web application with a specific Web container instance, which can have the effect of binding this Web application to a different set of ports, than other Web applications.A set of elements need to be set for such binding to specific ports.
web-container
This element indicates that this Web application should be deployed to the specified web container, instead of the default web container.Since there is only one Web container configured by default and it is not a must to have this element.
Pattern
If a simple name is not sufficient to distinguish the Web container, a full name pattern can be used to uniquely identify it. A pattern points to a resource located elsewhere in the server. Normally only the name is required, and between the name and the type of the reference, that's enough to identify the target. The groupID, artifactID, and version can be used to identify the module that holds the target resource, in case there is more than one matching resource in the dependencies of the current module.
gbean-link
Normally each Web container has a unique name, and only that name is needed to identify the target Web container. This element holds the name of the Web container that this Web application should be deployed to. The default Web container name is JettyWebContainer (for Jetty distributions) or TomcatWebContainer (for Tomcat distributions).
<------ FALTA TRADUCCION