http://java.developpez.com/tutoriels/servlets-java/?

page=page_3#LIII-A

III. Introducción al desarrollo

▲

Ahora que las presentaciones se hacen, les invito a manipular Servlets. Esta introducción al
desarrollo de servlets le dará los conocimientos básicos acerca de las tecnologías que son
cimientos sobre los que Servlets (como HTTP). Se describirá en detalle la instalación del motor
servlet Tomcat junto con Apache después de hacer las rondas de soluciones y justificó mi
elección y explicar con precisión qué forma proporciona un servlet, cómo y con qué
herramientas se desarrollan.
III-A. Los fundamentos de aplicaciones web a nivel de servidor
▲
III-A-1. Aplicaciones cliente-servidor
▲

El funcionamiento de una aplicación cliente-servidor puede ser descrito como sigue.

Un programa que se ejecuta en una máquina lógica que ofrece unas conexiones de apoyo a
otros equipos a través de una red ofrece sus servicios. En otra máquina lógica, ofreciendo
también admite conexiones a otros equipos a través de una red, se ejecuta un programa que
envía peticiones a máquinas que actúan como un servidor, al utilizar los servicios ofrecidos.
Imagen no disponible

Un programa de servidor puede manejar, en, múltiples solicitudes generales al mismo tiempo
a partir de los mismos o diferentes clientes. Un programa cliente puede generalmente utilizar
múltiples conexiones a las mismas o diferentes servidores simultáneamente.

Estas dos máquinas lógicas (debido a que el programa cliente puede ejecutarse en la misma
máquina física que el programa de servidor) utilizando un conjunto de protocolos para
comunicarse entre sí. Estos protocolos son un conjunto de reglas a seguir para comunicarse
dependiendo de la finalidad (transmisión de información confidencial, la transmisión rápida de
información importante, etc.).

Estos protocolos se colocan en varios niveles de la capa OSI que define la arquitectura lógica
de los medios de comunicación a través de una red en la mayoría de las máquinas. Estas capas
son más abstractos y orientado "aplicaciones" hasta más concretas y orientadas
"implementación física" abajo.

Por lo tanto las capas inferiores del modelo OSI utilizan para gestionar todas las
comunicaciones a través de una red, si bien es las capas superiores que ofrecen diferencias
notables a las aplicaciones de programadores y usuarios alto nivel.

Por tanto, estas capas superiores definen protocolos específicos para cada tipo de aplicaciones
que se pueden encontrar en una red: la transferencia de archivos (FTP), el envío y recepción de
correo electrónico (SMTP), la consulta web (HTTP) etc ..
El cliente y el servidor y luego conversar con los mismos protocolos, pero en el lado del
servidor proporciona los servicios, los beneficios para el cliente en otro. Un servidor, a través
de la separación de los protocolos orientados a la "aplicación" puede proporcionar el tipo de
servicio que desea. No está obligado a ofrecer todos los servicios existentes (solo sitio web de
consulta por ejemplo), pero puede.

Un cliente simultáneamente puede hacer que el servidor. La comunicación entre las

computadoras no es unidireccional.
III-A-1-a. El protocolo HTTP
▲

Para ilustrar y comprender mejor lo que sucede durante una comunicación entre un cliente
web (que puede ser un navegador u otra aplicación utilizando el protocolo HTTP) y un servidor
Web, voy a tratar de explicar un poco más en detalle la operación HTTP.

El servidor entra en modo de escucha en un puerto definido, que es normalmente el puerto

80, aunque esto no es obligatorio. Cada solicitud recibida del cliente, se crea un nuevo proceso
que se encargará de la solicitud. El diálogo puede comenzar, y luego el cliente debe enviar su
solicitud, que debe cumplir con el protocolo HTTP.

Estas solicitudes se envían al servidor web a través de la conexión que se establece entre el
cliente y el servidor y tomar la forma de datos convencionales (texto). Hay un gran número de
diferentes consultas, pero en realidad rara vez se utilizan muchas consultas. Apéndice A
describe todo tipo de consultas disponibles en el protocolo HTTP con una breve descripción. El
cliente entonces envía la solicitud, el análisis del servidor y devuelve una respuesta al cliente
(adaptado a su petición) a través de la misma conexión. La conexión se corta. El cliente debe
emitir solicitudes se ajustan a la versión del protocolo HTTP implementado por el servidor.
Generalmente Servidores recientes (como Apache) implementar la versión 1.1, mientras que
algunos servidores más antiguos sólo admiten la versión 1.0. Los servidores que soportan la
versión 1.1 del protocolo también apoyan, en general, la versión 1.0. La versión del protocolo
se especifica en la cabecera de la petición desde el cliente y la respuesta efectuada por el
servidor.

Para probar las conductas descritas en los ejemplos que doy, puede utilizar la herramienta de
telnet (disponible en todos los sistemas operativos dignos de ese nombre) de la siguiente
manera:

Elija

telnet adresse_ip_serveur_web 80

dirección_ip_servidor donde es la dirección IP del servidor web de destino (creo que ya lo

sabías ;-)). Simplemente va a entrar en la consulta a la solicitud que se encuentra disponible.
La parte principal de la aplicación en relación con el pedido del cliente, colocado en la primera
fila de la consulta. Determina la acción a realizar. Estos comandos son a veces con argumentos
que especifica el objeto sobre el que se relaciona el comando. La acción más utilizada está
recuperando un documento con el comando GET o POST (GET y HTTP POST son dos métodos
diferentes para realizar la misma acción). Este comando toma como argumento para recuperar
el recurso, es decir, la ruta de acceso al archivo a recuperar (esto no es una ruta absoluta, sino
relativa a la raíz del servidor). Por ejemplo :

Elija

GET /index.html HTTP / 1.0

recuperará el archivo index.html que se encuentra en la raíz del directorio de instalación del
servidor utilizando la versión 1.0 de HTTP.

En general, los clientes colocan un encabezado en su aplicación, como consecuencia de la

orden, por ejemplo, describiendo lo que son (nombre y número de versión de un ejemplo del
navegador) y lo que pueden aceptar (imágenes , texto en HTML para el mismo tipo de
software, por ejemplo). Algunos encabezados son opcionales y otros obligatorio, depende de
la aplicación y de la configuración del servidor Web al que se transmite la solicitud. Usted, por
ejemplo, añadir una cabecera que especifica un nombre de usuario y una contraseña si el
servidor Web está configurado de tal manera que no acepta personas desconocidas. Por
ejemplo :

Elija

GET / index.html HTTP / 1.0

Accept: text / html, image / gif
User-Agent: Mozilla / 4.0 (compatible; MSIE 4.0; X11 Linux 2.2.17)

indica que el cliente en el origen de la solicitud es el navegador Netscape (basado en Mozilla,

de ahí la aparición del nombre) que se ejecuta Linux y acepta el texto como HTML y GIF . La
solicitud de un cliente Web debe ser seguido por dos saltos de la línea para ser tenidos en
cuenta.

Una vez analizada la solicitud del cliente (cabecera y el cuerpo de la solicitud), el servidor tiene
todos los elementos para producir una respuesta. El primer elemento de la respuesta se llama
el estado que especifica la versión del protocolo HTTP usado, un código de estado y una breve
descripción de la condición. La cabecera de la respuesta se produce después de la línea de
estado. Éste se describe como el tipo de datos que se envían (texto ASCII, HTML, imágenes gif,
etc.). El servidor puede enviar los datos al navegador que analizarlos correctamente de
acuerdo con las directivas de la cabecera de la respuesta del servidor. Por ejemplo :

Elija
HTTP / 1.0 200 OK
Servidor: Apache / 1.3.14 mod_php4
Content-type: text / html

indica que la consulta puede ser tratada con éxito (código de estado 200 y la descripción del
código "OK") y es procesado por Apache en su versión 1.3.14. También se sabe que la
respuesta contiene sólo texto en formato HTML.

Una vez que esta cabecera envía al cliente, el servidor puede comenzar a enviar datos (el
archivo index.html si se basa en el ejemplo de aplicación anterior) mediante la separación de la
cabecera y los datos de dos líneas en blanco. Estas dos líneas en blanco son indispensables
indispensable.

Repito, después de enviar datos al cliente, la conexión se interrumpe, incluso si el cliente es

probable que emitir una solicitud de acceso a un recurso en el mismo servidor
inmediatamente. Se dice que el protocolo HTTP no es orientado a la sesión: no hay ninguna
manera de identificar a un usuario durante una serie de conectarse a un sitio Web. Ahora es
común que los usuarios realizan una serie de acciones lógicas para lograr un propósito
específico (comprar un producto en un sitio comercial, por ejemplo). Por tanto, es
problemático identificar correctamente esta suite lógica con las únicas herramientas
proporcionadas por el protocolo HTTP. Algunas herramientas de servlets que veremos en el
capítulo sobre el seguimiento de sesión están ahí para corregir esta deficiencia.
III-B. La implementación del servidor
▲

Ahora ha adquirido suficiente conocimiento sobre el protocolo HTTP y el funcionamiento de

las aplicaciones web del lado del servidor para ir a practicar. Con el fin de poner a prueba sus
primeros servlets, debe instalar el motor de servidor Web y servlet que ejecutarlos. Voy a
tratar en un primer momento para darle una visión general de las diferentes soluciones
existentes y compartir con ustedes mi elección y esta elección causas, y al final me guiderais
usted a través de la instalación del servidor.
III-B-1. Los diferentes tipos de soluciones
▲

En primer lugar, definir los diferentes tipos de servidores. Hay tres tipos diferentes de motores
de servlets:

Motores Servlets independientes.

Motores de servlets bordo.
motores Servlets externos.

Servlets motores independientes son una parte integral del servidor Web. Para tal cosa es
posible, debemos asumir que el servidor Web está desarrollado en Java. Un ejemplo de este
tipo de servidores es el servidor Java Web o Tomcat (que analizaremos en detalle la
configuración más adelante).
Motores servlets integrados son una combinación de una adición a un servidor web y una
implementación de la API Servlet. La adición (plugin) permite al servidor web para enrutar las
solicitudes de los clientes y los servlets relacionados con una máquina virtual contenida en el
proceso del servidor Web. Esta máquina virtual se ejecuta en un hilo separado que involucra la
operación del servidor web multiproceso, lo cual no es el caso de todos los servidores web (por
ejemplo Apache en Unix). Esta configuración proporciona un buen rendimiento debido a los
cambios de contexto son menos costosos, pero es limitada posibilidad de extensiones (un
servidor que soporta un gran número de solicitudes al mismo tiempo casi no será capaz de
responder a ellos).

Motores externos Servlets son una combinación de un plugin "injertados" en el servidor y una
máquina virtual que se ejecuta en el exterior del mismo. Para comunicarse entre ellos, el
enchufe y el proceso asociado a la máquina virtual mediante un mecanismo de comunicación
entre procesos, como sockets TCP / IP. Si por una petición final al respecto Servlets servidor
Web, se pasa la petición al motor servlet utilizando el mecanismo anteriormente mencionado.
Una desventaja de este método es la reducción en el rendimiento. Por contra, este tipo de
servidor es más estable en general (una parada desde el servidor Web no afecta el motor de
servlets y viceversa), y más extensible. Por otra parte, ya que la máquina virtual es externo al
servidor Web, se puede ejecutar en cualquier máquina, que le permite ejecutar el servidor
Web en una máquina diferente de aquel en que se arranca el motor de servlets. También
puede configurar varias máquinas virtuales a un solo Web2.2 servidor. En resumen, la
flexibilidad se gana puede ser interesante en muchos aspectos.

Generalmente, las personas que deseen prestar apoyo a los servlets en su servidor ya brindar
apoyo a otras tecnologías de desarrollo web del lado del servidor, o simplemente ofrecen
alojamiento de páginas estáticas. Es evidente que un motor de servlets, incluso si él puede
hacer un servidor web en la que se puede convertir en el modo independiente (como Tomcat o
Java Web Server), es mucho menos eficiente que productos especializados cuando es
necesario proporcionar diferentes Servlets de contenido (páginas estáticas, archivos, etc.). Por
tanto, es fácil de entender que es mejor elegir un motor de servlets "injertados" en un servidor
web existente con el fin de mantener su eficacia en relación con el contenido estático (el
servidor web que soporta) y la toma de contenido dinámico uso de servlets (el motor servlet
que lo soporta). Esto nos deja la elección entre una solución y dos (integrado o externo) Por
supuesto, es perfectamente posible trabajar con motores independientes a los fines del
desarrollo Servlets, recomiendo sólo para la producción.

Volvamos a los servidores de aplicaciones. Dije antes que a menudo eran una conexión entre
un servidor existente web, un motor servlet existente y herramientas "comercio" orientada y
más como la incorporación de los EJB y otras herramientas específicas para la actividad
industrial ( gestión de transacciones, relaciones con los clientes, etc.). son herramientas muy
afiladas, que suelen ser muy caros y requieren múltiples habilidades. Su uso y configuración es
similar a la solución más convencional, a menudo las herramientas de configuración fáciles de
utilizar para las manchas comunes, pero con respeto Servlets desarrollo estricto, que apenas
aporta nada (aparte de optimizaciones rendimiento o la fiabilidad en entornos específicos, a
menudo grandes sistemas como el S / 390). Vemos claramente que los aspectos interesantes
de estas soluciones más allá del alcance de mis habilidades y este libro, y por eso me ECAR
terais de mi elección. En conclusión acerca de estas soluciones, que a menudo son menos
flexibles de usar que las aplicaciones más tradicionales debido a su complejidad y su raza para
facilitar su uso. Los problemas reportados en listas de correo relacionadas con la preocupación
Servlets motor de configuración de la mayoría del tiempo este tipo de servidores.

Parece ser que el tipo de servidor que combina el mayor beneficio es el motor de servlets
externos conectados a un servidor Web de alto rendimiento a través de un plugin. De hecho,
como hemos visto, es un confiable, flexible y de gran alcance suficiente. Por otra parte, con un
poco de esfuerzo de configuración, este tipo de servidor puede además incluir un gran número
de características tales como EJB, dándoles acceso a los componentes de negocio tan caros
para los servidores de aplicaciones, o con el apoyo de varias máquinas virtual.

Ahora que hemos elegido (aunque yo te ayudé) el tipo de servidor para utilizar, elegir cuál usar
búsqueda.
III-B-2. La elección de la solución
▲

La elección de un servidor depende esencialmente rendimiento fuera sobre el contenido de

servicio distintos de servlets, dos criterios: la versión de la API Servlet apoyado y versión de JSP
soportado. De hecho, aunque las comparaciones de rendimiento entre las alternativas son
abundantes, no significan nada si no se refieren directamente a la aplicación que desea
ejecutar. Sobre la versión de la API soportada es más reciente, se puede hacer uso de
características útiles (por ejemplo, la versión 2.0 de la API Servlet no soporta
RequestDispatcher). El razonamiento es similar en lo que respecta JSP. Para obtener una visión
clara de estos dos criterios, los invito a que visite la siguiente URL:
http://java.sun.com/products/servlet/industry.html. Aquí, el sistema operativo elige no tiene
en cuenta la elección de motor de servlets, ya que este tipo de servidor es (generalmente)
programado en Java, cualquier sistema operativo con una aplicación la máquina virtual Java se
supone que funciona. Sin embargo, ya hemos elegido para acoplar el motor a un servidor Web
Servlets, debemos prestar atención a los servidores Web compatibles, así que podemos usar
esa pareja con el sistema operativo de nuestra elección.

Se puede ver que algunos servidores externos (es decir, que se puede acoplar a un servidor
Web, que no debe confundirse con la independiente) corresponden a estos dos criterios. La
elección que voy a proponer aquí sólo depende de las preferencias que no necesariamente va
a adherir, pero me gustaría tratar de justificar el rechazo de alternativas (como lo hice para la
elección del tipo de servidor).

En primer lugar WAIColRunner debe ser utilizado en conjunción con un servidor web Netscape
o Netscape Enterprise Server Fast Track (este último es una versión más ligera de la primera).
Esto limita en gran medida las opciones para el servidor Web, incluso si se encuentra
ampliamente distribuida en las empresas. Se trata de un motor de servlets pagar cuando uno
quiere obtener soporte técnico. Respecto Allaire JRun, ofrece, gracias a una atractiva suite
integrada JRun Estudio para el desarrollo de servlets (depuración remota, el rápido desarrollo,
etc.) y ofrece algunas características interesantes, tales como la compatibilidad con la mayoría
de los servidores web existente, pero vale la pena (a un precio entre 495 dólares y 18,395
dólares). Queda Caucho Resina del Apache Tomcat y Fundación. El primero tiene un
impresionante número de ventajas: es compatible con todos los servidores principales Web
corriendo (iPlanet, IIS, Apache), tiene herramientas interesantes como soporte para XSL y X ML
para gestionar documentos modelos (entre otros) e incluso soporta la versión 2.3 de la API
Servlet (que sólo está en la etapa de propuesta) 2.3. Sin embargo, el uso no es gratuito si se
trata de un entorno comercial. El último, usted comprenderá, está impulsando servlets en el
que llevo mi elección, Tomcat es la Fundación Apache. Lo elegí porque se ejecuta en un gran
número de sistemas operativos diferentes, está muy bien integrado con el servidor Apache
(pero también otros como IIS), y se distribuye bajo los términos con licencia de código abierto
(para que esté disponible). Estas características dan como resultado que es muy fácil de
documentar este motor de servlets, encontrar gente que sabe el mango y su desarrollo es muy
actif2.4. Además, no es necesario demostrar la eficacia del servidor Web Apache a la que se
asocia en general.

Ahora tenemos una solución flexible y potente basado en el motor servlet Tomcat y el servidor
Web Apache. Ahora te guiará en la instalación y configuración de esta solución, al
concentrarse en lo que puede beneficiar y dejar de consultar la documentación que viene con
el servidor para obtener más información.
III-B-3. La instalación de Tomcat y Apache
▲

Tomcat y Apache, como hemos dicho antes, ambos disponibles para un gran número de
diferentes sistemas operativos. Es imposible describir el proceso de instalación de estas
aplicaciones en todos los medios posibles. Sólo sé que la instalación en la familia Unix de
sistemas cambiará poco en el peor de los casos, y la instalación de Windows será diferente a
nivel de archivos a instalar (se descargará los binarios para Windows y no las fuentes para
Unix) y no requiere compilación. Voy a describir la instalación de Tomcat y Apache en un
sistema Linux, en particular una distribución Debian en la versión 2.2. Se reconoce aquí que
usted tiene un compilador para programas escritos en C que funciona y es compatible con gcc.
Para comprobarlo, introduzca el comando:

Elija

-version gcc

que debe mostrar la versión de gcc instalado en su sistema.

III-B-3-a. La instalación del entorno de desarrollo de Java
▲

Antes de instalar Tomcat, es necesaria la instalación de un entorno de desarrollo Java. Por eso,
yo le aconsejo que use la jdk1.3 ofrece por Sun. Si usted tiene un kit de desarrollo de Java
tarde o igual a la versión 1.1, puede omitir este paso (aunque por razones obvias de
rendimiento y características que usted puede ser que desee instalar la última versión del kit
Desarrollo). Se puede descargar como tar.gz (distribución independiente) en la siguiente URL:
http://java.sun.com/j2se/1.3/download-linux.html. Después de descargar el archivo, debe
descomprimir y desempaquetar en el directorio de su elección (por ejemplo /usr/local/jdk1.3)
con el siguiente comando:

Elija

xfvz j2sdk tar-1_3_0-linux.bin -C / usr / local

Una vez hecho esto, vaya al directorio $ JAVA_HOME / bin, donde $ JAVA_HOME es el
directorio donde está instalado el JDK (en nuestro ejemplo /usr/local/jdk1.3/bin) de la
siguiente manera:

Elija

/usr/local/jdk1.3/bin cd

A continuación, ejecute el comando:

Elija

./javac

Si recibe un mensaje que indica todas las opciones disponibles para el compilador Java está
ganado. con el fin de beneficiar a todas las aplicaciones Java que pueden utilizar (como
Tomcat) del entorno instalado, le sugiero que añadir las herramientas lingüísticas en su camino
como esto:

Elija

export PATH = $ PATH: /usr/local/jdk1.3/bin

siempre teniendo en cuenta que ha instalado el JDK en /usr/local/jdk1.3. Ahora usted puede
utilizar las herramientas del lenguaje (compilador, el visor de applets, etc.) en cualquier parte
de la vista de árbol del sistema de archivos.

Ahora que el entorno de desarrollo para Java está instalado, vamos a ir a la instalación del
motor servlet Tomcat.
III-B-3-b. La instalación de Tomcat
▲

Ahora vamos a proceder a instalar los servlets motor. Para ello, primero debe descargar la
versión 3.2.1 del Tomcat disponible en la siguiente URL:
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.1/bin/. Esta versión no es la
última versión de Tomcat. De hecho, el desarrollo de Tomcat es muy activa, y los nuevos
conceptos se introducen regularmente.

Por ejemplo, en relación con el protocolo de comunicación entre el servidor Web Apache y
motor servlet Tomcat, un nuevo proceso ha surgido desde la versión 3.2.1: JK. mod_jk (módulo
dinámico cargado por Apache en el arranque para tener en cuenta JK) es para el mediano
plazo, la sustitución de mod_jserv (el protocolo de comunicación entre el servidor Web y
servlets motor que voy a describir en esta instalación). JK aporta una serie de beneficios tales
como soporte para múltiples diferentes servidores web a través de la misma interfaz (IIS,
Netscape Server, Apache 2.x, etc.), la correcta gestión de HTTPS (Secure HTTP a través del uso
SSL). Además, JK no es una adaptación de Apache JServ diferencia mod_jserv tanto, incluye
código innecesario.

Sin embargo, la novedad de mod_jk no me permite dominar lo suficiente como para ofrecer
asistencia sobre configuraciones complejas, a diferencia mod_jserv sé mejor. Por otra parte,
mod_jserv sigue siendo mucho más común que mod_jk. Así que voy a explicar la configuración
básica de Tomcat con mod_jk y mod_jserv, y entonces le sugiero que mod_jserv con la
configuración avanzada.

Para instalar Tomcat, le sugiero que descargar las fuentes de la última versión estable a la
siguiente URL: http://jakarta.apache.org/builds/tomcat/release/v3.2.1/src/. La última versión
estable es 3.2.1, por lo que ahora debe descargar el archivo jakarta-tomcat-3.2.1-src.tar.gz.

A continuación, descargar otras herramientas:

JSSE para Java Secure Socket Extension permite establecer conexiones seguras a través de
una red (mediante SSL, por ejemplo) entre dos máquinas. Http://java.sun.com/products/jsse/
Disponible.
Ant: es un gestor de compilación condicional, así como hacer de Unix. Permite, escribiendo
archivos de descripción de compilación, recompilar sólo los archivos que han cambiado. Esto
es útil para compilar programas grandes (como Tomcat).
Http://jakarta.apache.org/builds/ant/release/v1.2/src/jakarta-ant-src.tar.gz Disponible.
API JAXP Java para procesamiento de XML puede analizar archivos en formato XML.
Http://java.sun.com/xml/download.html Disponible.
Clases de la API Servlet que implementan los servlets API.
Http://java.sun.com/products/servlet/download.html Disponible.

Una vez descargado estas herramientas, debe crear un directorio para la creación de una
versión binaria de Tomcat: vamos a utilizar / usr / / tomcat-dist locales:

Elija

mkdir / usr / / tomcat-dist locales

Descomprimir entonces todos los archivos descargados en este directorio:

Elija

xfvz jakarta-tomcat tar-3.2.1-src.tar.gz -C / usr / / tomcat-dist locales

jsse-1_0_2-gl.zip descomprimir -d / usr / / tomcat-dist locales
mkdir / usr / / tomcat-dist / jakarta-ant locales
tar xfvz jakarta-ant-src.tar.gz -C / usr / / tomcat-dist / jakarta-ant locales
jaxp-1_0_1.zip descomprimir -d / usr / / tomcat-dist locales
servlet-2_2b.zip descomprimir -d /usr/local/jdk1.3/jre/lib/ext

Ahora instalar paquetes de Java necesarios para compilar Tomcat. Ya hemos copiado los
servlets paquete en /usr/local/jdk1.3/jre/lib, tenemos que hacer lo mismo con los archivos
parser.jar jaxp.jar y la versión de JAXP que ha recuperado y con archivos jnet.jar, jcert.jar
jsse.jar y has recuperado del archivo de JSSE. Este proceso ahorra agregar la ruta de acceso a
estos archivos en la variable de entorno CLASSPATH, pero también se puede utilizar este
método.

Ahora tenemos que compilar Ant. Para ello, vaya al directorio donde ha descomprimido y
entrar en:

Elija

./build.sh

compilación debería tener lugar sin ningún problema. Si un error de compilación mencionó
que una clase o un paquete no se encuentra, debe comprobar que el frasco antes mencionado
están en la ubicación correcta (o el CLASSPATH contiene buenos valores.).

Ahora tenemos que compilar Tomcat. Para ello, la posición en el directorio donde ha
descomprimido y ejecución:

Elija

./build.sh dist

Este comando va a construir una "distribución" binaria idéntica a la que se puede descargar
desde el sitio web de la Fundación Apache, pero adaptado a la configuración. Después de la
compilación tiene éxito, se puede probar el funcionamiento de Tomcat.

Para ello, vaya al directorio "bin" de su distribución de Tomcat que debería ser $
TOMCAT_HOME / build / tomcat / bin si TOMCAT_HOME $ / usr / / tomcat-dist local. Inicie la
sesión como usuario "root":

Elija
./startup.sh

Debería ver una serie de mensajes aparecerá indicando el inicio de Tomcat. A continuación,
abra un navegador web para acceder y solicitar la siguiente URL: http://127.0.0.1:8080/. Si
obtiene la primera página del servidor Tomcat, todo funciona a la perfección.

En ese momento, Tomcat se ejecuta en modo independiente, que no es lo que queremos (ver
choix_solution). Ahora vamos a describir su asociación con el servidor Web Apache para hacer
un motor servlet externo.
III-B-3-c. Instalación y configuración de Apache
▲

Tenga la seguridad, esta parte de la instalación del ambiente de trabajo es mucho más simple
que la anterior.

En primer lugar, debe descargar una versión de Apache 1.3.9 anterior, el último si es posible
(1.3.14) en la siguiente URL: http://httpd.apache.org/dist/apache_1.3.14 .tar.gz.

Luego hay que descomprimir en la carpeta de su elección, por ejemplo, / / local / src usr así:

Elija

xfvz apache_1.3.14.tar.gz tar -C / usr / local / src

Esto debería crear el /usr/local/src/apache-1.3.14 directorio. Ir a este directorio con el

comando:

Elija

/usr/local/src/apache-1.3.14 cd

y comenzar a configurar el script de creación de esta manera:

Elija

./configure --enable-module = tan

Esto permitirá que el apoyo para los módulos cargables dinámicamente, lo que será necesario
para la comunicación entre Apache y Tomcat. Una vez que el script de configuración, ejecute el
siguiente comando:

Elija

make install
que va a compilar e instalar el servidor Web Apache en el directorio / usr / local / apache.
Ahora, para la gestión de Tomcat. Como he descrito anteriormente, hay dos maneras
diferentes de proceder (ver jk_versus_jserv).
III-B-3-d. Configuración mod_jserv
▲

Para habilitar Apache utilizar mod_jserv para comunicarse con Tomcat debe compilar el
módulo mod_jserv.so cargable. Para ello, cambiar la posición de sí mismo en el directorio de
origen del módulo:

Elija

/usr/local/tomcat-dist/jkarta-tomcat-3.2.1-src/src/native/apache/jserv cd

si usted ha hecho la misma manipulación que los descritos anteriormente