BEA WebLogic: Guía de Administración

Un Aplicaci�n Web contiene recursos de aplicaci�n como Servlets, JavaServer Pages (JSP), librer�as de etiquetas JSP, y recursos est�ticos como p�ginas HTML y ficheros de im�genes. Una aplicaci�n Web tambi�n peude definir enlaces a recursos fuera de la aplicaci�n como Enterprise JavaBeans (EJB). Las aplicaciones Web usan un descriptor de despliegue est�ndar J2EE en conjunci�n con un descriptor de despliegue espec�fico de WebLogic para definir los recursos y otros par�metros de operaci�n.

Las p�ginas JSP y los servlets HTTP pueden acceder a todos los servicios y APIs disponibles en el Servidor WebLogic. Estos servicios incluyen EJBs, conexiones a bases de datos mediante JDBC, JavaMessaging Service (JMS), XML, y m�s.

Las aplicaciones Web usan una estructura de directorio est�ndar definida en la especificaci�n J2EE y pueden desplegarse como una colecci�n de ficheros que usan esta estructura de directorio (este tipo de despliegue se llama formato de directorio expandido) o como un fichero individual llamado un fichero .war. El despliegue de aplicaciones Web en formato de directorio expandido se recomienda principalmente mientras desarrollamos nuestra aplicaci�n. Mientras que en entornos de producci�n se recomienda desplegar una aplicaci�n Web usando un fichero .war.

�Pasos para Desplegar una Aplicaci�n Web

Para desplegar una Aplicaci�n Web:

1. Distribuimos los recursos (servlets, JSPs, ficheros est�ticos y descriptores de despliegue) en el formato de directorio prescrito. Para m�s informaci�n puedes ver Estructura de Directorio.
2. Escribimos el descriptor de despliegue de la aplicaci�n Web (web.xml). En este paso registramos los servlets, definimos los par�metros de inicializaci�n de los servlets, registramos las librer�as de etiquetas JSP, definimos las restricciones de seguridad, y definimos otros par�metros de la Aplicaci�n Web.
3. Creamos el descriptor de despliegue espec�fico de WebLogic (weblogic.xml). En este paso definimos las propiedades JSP, los m�peos JNDI, los mapeos de los roles de seguridad y los par�metros de sesi�n HTTP. Si no necesitamos definir ninguno de los atributos de este fichero, no necesitamos crearlo.
4. Almacenamos los ficheros de la estructura de directorios anterior en un fichero .war. S�lo usamos el archivado cuando la Aplicaci�n Web est� preparada para desplegarse en un entorno de producci�n. (Durante el desarrollo podriamos encontrar m�s conveniente para actualizar los componentes individuales de nuestra aplicaci�n Web, desplegarla en el formato de directorio extendido). Para crear un archivo .war, usamos esta l�nea de comandos desde el directorio ra�z que contiene nuestra aplicaci�n Web:

   jar cv0f myWebApp.war .
   

   Este comando crea un fichero de Aplicaci�n Web llamado myWebApp.war.
5. Desplegar la Aplicaci�n Web sobre el Servidor WebLogic de una de estas dos formas: usando la Consola de Administraci�n o copiando la Aplicaci�n Web dentro del directorio de aplicaciones de nuestro dominio.

   Para desplegar una Aplicaci�n Web en formato war usando la Consola de Administraci�n (no podemos desplegar una Aplicaci�n Web en formato de directorio extendido usando este procedimiento):

   • Seleccionamos el nodo Web Applications en el panel izquierdo.
   • Pulsamos Install a New Web Application.
   • Navegamos a la localizaci�n del fichero .war en nuestro sistema de ficheros.
   • Pulsamos Upload.

   Este procedimiento crea una nueva entrada en el fichero config.xml que contiene la configuraci�n para nuestra Aplicaci�n Web y copia nuestra Aplicaci�n a una localizaci�n interna.

   Para desplegar una Aplicaci�n Web (en formato archivado o expandido) copiando:

   • Copiamos un fichero .war o un directorio de m�s alto nivel que contiene una Aplicaci�n Web en un formato de directorio extendido en el directorio mydomain/config/applications de nuestra distribuci�n WebLogic Server. (Donde mydomain es el nombre de nuestro dominio). Tan pronto como se complete la copia, WebLogic Server despliega autom�ticamente la Aplicaci�n Web.
   • (Opcional) Usamos la Consola de Administraci�n para configurar la Aplicaci�n Web. Una vez que cambiamos cualquier atributo (ver paso 6) de la Aplicaci�n Web, la configuraci�n es escrita en el fichero config.xml y la Aplicaci�n Web ser� desplegada est�ticamente la pr�xima vez que reinicemos el Servidor WebLogic. Si no usamos la Consola de Administraci�n, nuestra Aplicaci�n Web todav�a es desplegada autom�ticamente cada vez que arrancamos el Servidor WebLogic, incluso aunque la informaci�n de configuraci�n no se haya grabado en el fichero config.xml.

     Nota: Si despliegas tu Aplicaci�n Web en formato expandido, debes leer Modificar Componentes de una Aplicaci�n Web.

     Nota: Si modificamos cualquier componente de un fichero .war en su localizaci�n original en nuestro sistema de ficheros, debemos re-desplegar nuestro fichero .war subi�ndolo de nuevo desde la Consola de Administraci�n.

6. Asignamos atributos de despliegue a nuestra Aplicaci�n Web:
   • Abrimos la Consola de Administraci�n.
   • Seleccionamos el nodo Web Applications.
   • Seleccionamos nuestra Aplicaci�n Web.
   • Asignamos nuestra Aplicaci�n Web a un Servidor WebLogic, a un Cluster o a un Host Virtual.
   • Seleccionamos la pesta�a File y definimos los atributos apropiados.

�Estructura de Directorio

Desarrollamos nuestra Aplicaci�n Web dentro de una estructura de directorio espec�fica para que pueda ser archivada o desplegada sobre un Servidor WebLogic, u otro servidor compatible con Servlet 2.2. Todos los servlets, clases, ficheros est�ticos y otros recursos que pertenecen a una Aplicaci�n Web est�n organizados bajo un �rbol de directorios. La ra�z de este �rbol define el documento ra�z de nuestra Aplicaci�n Web. Todos los ficheros bajo el directorio ra�z pueden servirse a los clientes, excepto los fichero bajo los directorios especiales WEB-INF y META-INF localizados bajo el directorio ra�z. Nombramos el directorio ra�z con el nombre de nuestra Aplicaci�n Web. Este nombre se usar� para resolver las solictudes de componentes de la Aplicaci�n Web.

Los ficheros privados deben situarse en el directorio WEB-INF, bajo el directorio ra�z. Todos los ficheros que haya en este directorio son privados, y no ser�n servidos a los clientes.

• WebApplicationName/
  Situamos nuestros ficheros est�ticos, como ficheros HTML o JSP en este directorio (o un subdirectorio). Este directorio es el documento ra�z de nuestra Aplicaci�n Web.
  • /WEB-INF/web.xml
    El descriptor de despliegue de la Aplicaci�n Web que la configura.
  • /WEB-INF/weblogic.xml
    El descriptor de despliegue espec�fico de WebLogic que define c�mo se mapen los recursos nombrados en el fichero web.xml a los recursos residentes en alg�n lugar del Servidor webLogic. Este fichero tambi�n se usa para definir atributos de sesiones JSP y HTTP.
  • /WEB-INF/classes
    Contiene las clases del lado del servidor como servlets HTTP y clases de utilidad.
  • /WEB-INF/lib
    Contiene los ficheros .jar usados por la Aplicaci�n Web.

�Desplegar y Re-Desplegar Aplicaciones Web

El procedimiento que usamos para despelgar y re-despelgar una Aplicaci�n Web depende de si la vamos a desplegar en formato expandido o comprimido. Cuando modificamos un componente de una Aplicaci�n Web tambi�n debemos re-despelgarla sobre el Servidor WebLogic para servir el componente modificado. Estos procedimientos se describen en esta secci�n.

�Modificar Componentes de una Aplicaci�n Web

Cuando modificamos cualquier componente de una Aplicaci�n Web (como una clase Servlet, un fichero HTML o JSP, o uno de los descriptores de despliegue), la nueva versi�n del componente no puede ser servida por el Servidor WebLogic hasta que hayamos re-desplegado la Aplicaci�n Web. El procedimiento usado para re-despelgar depende de si la desplegamos usando el formato comprimido (.war) o expandido.

Componentes en formato .war

Cuando editamos un componente de una Aplicaci�n Web que se ha desplegado en un fichero war, necesitamos re-jar (re-empaquetar) el archivo y luego subir el fichero .war usando uno de los procedimientos descritos en el paso 5 de Pasos para Desplegar una Aplicaci�n Web.

Componentes en Formato de Directorio Expandido

Cuando editamos un componente de una Aplicaci�n Web que se ha desplegado en formato de directorio expandido, debemos tener en mente que WebLogic actualiza los componentes de forma diferente:

• Ficheros JSP
  Los ficheros JSP se re-despliegan bas�ndose en la selecci�n del atributo pageCheckSeconds que definimos en el descriptor de despliegue espec�fico de WebLogic, weblogic.xml, de nuestra Aplicaci�n Web. Este atributo define el intervalo de tiempo en el cual el Servidor WebLogic chequea los ficheros JSP para ver si han sido modificados. Si se selecciona a 0 (cero), las p�ginas son chequeadas en cada petici�n. Si seleciona a -1, se desactiva el chequeo y recompilaci�n de las p�ginas.

  Nota: Los ficheros JSP se redespliegan autom�ticamente s�lo en el Servidor de Administraci�n. Si queremos que los JSPs sean re-desplegados en el servidores controlados dirigos por la Aplicaci�n Web, debemos re-desplegar la Aplicaci�n Web (ver m�s abajo).

• Servlets
  Los servlets JSP se re-despliegan bas�ndose en la selecci�n del atributo Reload Period que definimos en el descriptor de despliegue espec�fico de WebLogic, weblogic.xml, de nuestra Aplicaci�n Web. Este atributo define el intervalo de tiempo en el cual el Servidor WebLogic chequea las clases Servlets para ver si han sido modificadas. Si se selecciona a 0 (cero), las clases son chequeadas en cada petici�n. Si seleciona a -1, el Servidor WebLogic no chequear� para ver si las clases han sido modificadas.
• HTML y otros ficheros est�ticos
  Si modificiamos un HTML u otro fichero est�tico, como un fichero de imagen o de texto, debemos re-desplegar la Aplicaci�n Web para que el Servidor WebLogic pueda reconocer los cambios.

�Re-Desplegar una Aplicaci�n Web

Usamos uno de estos tres procedimientos para re-desplegar una Aplicaci�n Web:

• Usando la Consola de Administraci�n:
  1. Seleccionamos el nodo Web Application.
  2. Des-seleccionamos la caja Deployed en el panel derecho.
  3. Pulsamos Apply.
  4. Seleccionamos la caja Deployed en el panel derecho.
  5. Pulsamos Apply.
• Modificando el fichero REDEPLOY:
  1. Creamos un subdirectorio llamado WEB-INF, bajo el directorio ra�z de nuestra Aplicaci�n Web.
  2. Creamos un fichero vac�o llamado REDEPLOY y lo grabamos en el directorio WEB-INF.
  3. Para re-desplegar la Aplicaci�n Web, modificamos el fichero REDEPLOY abri�ndolo, modificando los contenidos (a�adir un espacio es la forma m�s f�cil de hacer esto), y luego grabando el fichero. De forma alternativa, en m�quinas UNIX, podemos usar el comando touch sobre el fichero REDEPLOY.
• Copiando de nuevo el fichero war en el directorio applications (s�lo se aplica al despliegue autom�tico).

�Desplegar Aplicaciones Web como parte de una Aplicaci�n Enterprise

Podemos desplegar una Aplicaci�n Web como parte de una Aplicaci�n Enterprise. Una Aplicaci�n Enterprise es una unidad de despliegue J2EE que empaqueta juntas Aplicaciones Web, EJBs y Adaptadores de Recursos en una s�la unidad desplegable. Si desplegamos una Aplicaci�n Web como parte de una Aplicaci�n Enterprise, podemos especificar un string que se usa en lugar del nombre real de la Aplicaci�n Web cuando el Servidor WebLogic sirve una petici�n para la Aplicaci�n Web. Especificamos el nuevo nombre con el elemento <context-root> en el descriptor de despliegue application.xml para la Aplicaci�n Enterprise.

Por ejemplo, para una Aplicaci�n Web llamada oranges, normalmente solicitar�amos un recurso de esa Aplicaci�n Web con una URL como esta:

http://host:port/oranges/catalog.jsp

Si la Aplicaci�n Web oranges se empaqueta en una Aplicaci�n Enterprise, podemos especificar un valor para el <context-root> como se ve en el siguiente ejemplo:

<module>
<wedestacar>
<web-uri>oranges.war</web-uri>
<context-root>fruit</context-root>
</wedestacar>
</module>

Entonces usar�amos la siguiente URL para acceder al mismo recurso de la Aplicaci�n Web oranges:

http://host:port/fruit/catalog.jsp

�URIs y Aplicaciones Web

Construirmos la URL usada para acceder a una Aplicaci�n Web desde un cliente usando el siguiente patr�n:

http://hoststring/ContextPath/servletPath/pathInfo

donde:

• hoststring
  es el nombre del host que es mapeado a un host vritual o hostname:portNumber
• ContextPath
  es el nombre de nuestra Aplicaci�n Web.
• servletPath
  es un servlet que est� mapeado a servletPath.
• pathInfo
  es la porci�n que resta de la URL, normalmente un nombre de fichero.

Si estamos usando hosting virtual, podemos sustituir el nombre del host vrital por la porci�n hoststring de la URL.

�Configurar Servlets

Los Servlets se registran o configuran como una parte de una Aplicaci�n Web. Para registrar un servlet, a�adimos varias entradas al descriptor de despliegue de la Aplicaci�n Web. La primera entrada bajo, el elemento <servlet> define el nombre del servlet y la clase compilada que ejecuta el servlet. Este elemento tambi�n contiene definiciones para los par�metros de inicializaci�n y roles de seguridad del servlet. La segunda entrada, bajo el elemento <servlet-mapping> define el patr�n URL que llama este servlet.

�Mapeo de Servlets

El mapeo de Servlets controla el modo en que accedemos a un servlet. Los siguientes ejemplo, demuestran algunas de las formas que podemos usar para mapear servlets en nuestra aplicaci�n Web.

<servlet>
  <servlet-name>watermelon</servlet-name>
  <servlet-class>myservlets.watermelon</servlet-class>
</servlet>

<servlet>
  <servlet-name>garden</servlet-name>
  <servlet-class>myservlets.garden</servlet-class>
</servlet>

<servlet>
  <servlet-name>list</servlet-name>
  <servlet-class>myservlets.list</servlet-class>
</servlet>

<servlet>
  <servlet-name>kiwi</servlet-name>
  <servlet-class>myservlets.kiwi</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>watermelon</servlet-name>
  <url-pattern>/fruit/summer/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>garden</servlet-name>
  <url-pattern>/seeds/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>list</servlet-name>
  <url-pattern>/seedlist</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>kiwi</servlet-name>
  <url-pattern>*.abc</url-pattern>
</servlet-mapping>

�Par�metros de Inicializaci�n de Servlets

Definimos los par�metros de inicializaci�n para los servlets en el descriptor de despliegue de la Aplicaci�n Web, en el elemento <init-param> del elemento <servlet>, usando etiquetas <param-name> y <param-value>. Por ejemplo, el siguiente listado de configuraci�n de los par�metros de inicializaci�n de Servlets:

<servlet>
  <servlet-name>HelloWorld2</servlet-name>
  <servlet-class>examples.servlets.HelloWorld2</servlet-class>

  <init-param>
    <param-name>greeting</param-name>
    <param-value>Welcome</param-value>
  </init-param>

  <init-param>
    <param-name>person</param-name>
    <param-value>WebLogic Developer</param-value>
  </init-param>
</servlet>

�Configurar JSP

Desplegamos los ficheros JSP situ�ndolos en la ra�z (o en un subdirectorio bajo la ra�z) de una Aplicaci�n Web. Los par�metros de configuraci�n adicionales para JSP est�n definidos en el elemento <jsp-descriptor> del descriptor de despliegue espec�fico de WebLogic, weblogic.xml. Estos par�metros definen las siguientes funcionalidades:

• Opciones del compilador JSP.
• Depurado.
• La frecuencia del chequeo que el Servidor WebLogic hace buscando JSPs actualizados que necesitan ser recompilados.
• Codificaci�n de caracteres

�Configurar Librer�as de Etiquetas JSP

Weblogic Server, en concordancia con la especificaci�n Servlet 2.2 proporciona la habilidad de crear y usar etiquetas JSP personalizadas. Estas etiquetas son clases Java que pueden ser llamadas desde dentro de un p�gina JSP. Para crear etiquetas JSP personalizadas, las situamos en una librer�a de etiquetas y definimos su comportamiento en un descriptor de librer�a de etiquetas (TLD). Este TLD debe estar disponible para la Aplicaci�n Web que contiene el JSP defini�ndolo en el descriptor de despliegue de la Aplicaci�n Web. Es una buena idea situar el fichero TLD en el directorio WEB-INF de nuestra Aplicaci�n Web, porque este directorio nunca est� disponible p�blicamente.

En el descriptor de despliegue de la Aplicaci�n Web, definimos un patr�n URI para la librer�a de etiquetas. Este patr�n URI debe corresponder con al valor de la directiva taglib en nuestras p�ginas JSP. Tambi�n definimos la localizaci�n del TLD. Por ejemplo, si la directiva taglib en la p�gina JSP es:

<%@ taglib uri="myTaglib" prefix="taglib" %>

y el TLD est� localizado en el directorio WEB-INF de nuestra Aplicaci�n Web, podr�amos crear la siguiente entrada en el descriptor de despliegue de la Aplicaci�n Web:

<taglidestacar>
  <taglib-uri>myTaglib</taglib-uri>
  <tablig-location>WEB-INF/myTLD.tld</taglib-location>
</taglidestacar>

WebLogic Server tambi�n incluye muchas etiquetas JSP personalizadas que podemos usar en nuestras aplicaciones. Estas etiquetas realizan cacheo, facilitan la consulta de control de flujo basado en par�metros, y facilitan la iteraci�n sobre conjuntos de objetos.

�Configurar P�ginas de Bienvenida

WebLogic Server nos permite seleccionar una p�gina que es servida por defecto si la URL solicitada es un directorio. Esta caracter�stica puede hacer nuestra site m�s f�cil de usar, porque el usuario puede teclear una URL sin dar un nombre de fichero espec�fico.

Las p�ginas de bienvenida se definen a nivel de Aplicaci�n Web. Si nuestro servidor est� hospedando varias Aplicaciones Web, necesitamos definir p�ginas de bienvenida separadas para cada Aplicaci�n Web.

Para definir las p�ginas de bienvenida, editamos el descriptor de despliegue de la Aplicaci�n Web, web.xml. Si no definimos nuestra p�gina de bienvenida, el Servidor WebLogic buscar� los siguientes ficheros en el siguiente orden y servir� el primero que encuentre:

1. index.html
2. index.htm
3. index.jsp

�Seleccionar un Servlet por Defecto

Cada Aplicaci�n Web tiene un Servlet por defecto. Este servlet puede ser un servlet que especifiquemos nosotros, o, si no lo especificamos, el Servidor WebLogic usa un servlet interno llamado FileServlet como servlet por defecto. Para m�s informaci�n puedes ver Como Resuelve las Peticiones HTTP el Servidor WebLogic.

Podemos registrar cualquier servlet como servlet por defecto. Escribir nuestro propio servlet por defecto nos permite usar nuestra propia l�gica para decidir c�mo manejar una petici�n que cae dentro del servlet por defecto.

Seleccionar un servlet por defecto reemplaza el FileServlet y deber�a hacerse cuidadosamente, porque FileServlet se usa para servir la mayor�a de los ficheros, como ficheros de texto, HTML, im�genes, etc. Si esperamos que nuestro servlet por defecto sirva dichos ficheros, necesitaremos escribir esa funcionalidad en nuestro servlet por defecto.

Para seleccionar un servlet por defecto definido por el usuario:

1. Definimos nuestro servlet como se describe en Configurar Servlets.
2. Mapeamos nuestro servlet por defecto con un patr�n url de �/�. Esto har� que nuestro servlet por defecto responda a todos los tipos de ficheros excepto aquellos con extensi�n *.htm o *.html, que son mapeados internamente a FileServlet.
   Si tambi�n queremos que nuestro servlet por defecto responda a los ficheros que terminan en *.htm o *.html, debemos mapear dichas extensiones hacia nuestro servlet por derecto, adem�s de mapear �/�. Para m�s informaci�n sobre el mapeo de servlets puedes ver Configurar Servlets.
3. Si todav�a queremos que FileServlet sirva los ficheros con otras extensiones, mapeamos dichas extensiones hacia FileServlet (adem�s de mapearlas hacia nuestro servlet por defecto). Por ejemplo, si queremos que FileServlet sirva los ficheros gif, mapeamos *.gif hacia FileServlet.

�C�mo Resuelve WebLogic Server Peticiones HTTP

Cuando WebLogic Server recibe una petici�n HTTP, la resuelve analizando las distintas partes de la URL y usando esta informaci�n para determinar qu� aplicaci�n Web o servidor deber�a manejarla. Abajo tenemos varios ejemplos de combinaciones de peticiones para Aplicaciones Web, host virtuales, servlets, JSPs y ficheros est�ticos y el respuesta resultante.

La siguiente tabla proporciona algunos ejemplos de URLs y los ficheros servidos por el Servidor WebLogic. La columna "Index Directories Checked " se refiere al atributo Index Directories que controla si se ofrece un listado de directorio si no se solicita ning�n fichero espec�ficamente. Seleccionamos Index Directories usando la Consola de Administraci�n, sobre el nodo Web Applications, bajo la pesta�a Configuration/Files.

�Personalizar Respuestas de Error HTTP

Podemos configurar WebLogic Server para responder con nuestras p�ginas Web personalizadas u otros recursos HTTP cuando ocurre un error HTTP o una excepci�n Java particular, en lugar de responder con las p�ginas de respuesta de error est�ndars de WebLogic Server.

Definimos las p�ginas de error personalizadas en el elemento <error-page> del descriptor de despliegue de la Aplicaci�n Web (web.xml).

�Usar CGI con WebLogic Server

WebLogic Server proporciona funcionalidades para soportar nuestros scripts Common Gateway Interface (CGI). Para nuevos proyectos, sugerimos usar Servlets HTTP o JavaServer Pages.

WebLogic Server soporta todos los CGI mediante un servlet interno de WebLogic llamado CGIServlet.TouseCGI, registrando el CGIServlet en el descriptor de despliegue de la Aplicaci�n Web.

�Configurar WebLogic Server para usar CGI

Para configurar CGI en WebLogic Server:

1. Declaramos CGIServlet en nuestra Aplicaci�n Web usando los elementos <servlet> y <servlet-mapping>. el nombre de la clase para el CGIServlet es weblogic.servlet.CGIServlet.
2. Registramos los siguientes par�metros de inicializaci�n para CGIServlet definiendo los siguientes elementos <init-param>:
   • cgiDir
     El path al directorio que contiene nuestros scripts CGI. Podemos especificar varios directorios, separado por un �;� (Windows) o un �:� (Unix). Si no especificamos cgiDir, el directorio por defecto ser� un directorio llamado cgi-bin bajo la ra�z de la Aplicaci�n Web.
   • extension mapping
     Mapea una extensi�n de fichero hacia el int�rprete o ejecutable que ejecuta el script. Si el script no requiere un ejecutable, se podr�a omitir este par�metro de inicializaci�n.
     Los mapeos de extensiones de <param-name> deben empezar con un asterisco seguido por un punto, seguido por la extensi�n de fichero, por ejemplo: *.pl.
     El <param-value> contiene el path del int�rprete o ejecutable que ejecuta el script. Podemos crear varios mapeos creando elementos <init-param> para cada uno.

Entradas de ejemplo incluidas en el descriptor de despligue de la aplicaci�n Web cuando se registra CGIServlet:

<servlet>
  <servlet-name>CGIServlet</servlet-name>
  <servlet-class>weblogic.servlet.CGIServlet</servlet-class>

  <init-param>
    <param-name>cgiDir</param-name>
    <param-value>
      /bea/wlserver6.0/config/mydomain/applications/myWebApp/cgi-bin
    </param-value>
  </init-param>

  <init-param>
    <param-name>*.pl</param-name>
    <param-value>/bin/perl.exe</param-value>
  </init-param>
</servlet>
...
<servlet-mapping>
  <servlet-name>CGIServlet</servlet-name>
  <url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>

�Solicitar un Script CGI

La URL usada para solicitar un script perl debe seguir el patr�n:

http://host:port/myWebApp/cgi-bin/myscript.pl

donde:

• host:port
  es el nombre del host y el n�mero de puerto del Servidor WebLogic
• cgi-bin
  es el nombre del patr�n url mapeado al CGIServlet,
• myWebApp
  es el nombre de nuestra aplicaci�n Web
• myscript.pl
  es el nombre del script Perl que est� localizado en el directorio especificado por el par�metro de inicializaci�n cgiDir.

�Servir Recursos del Classpath con el ClasspathServlet

Si necesitamos servir clases u otros recursos desde el CLASSPATH del sistema, o desde el directorio WEB-INF/classes de la aplicaci�n Web, podemos usar un servlet especial llamado ClasspathServlet. Este servlet es �til para aplicaciones que usan applets o clientes RMI y requieren acceder a clases del lado del servidor. ClasspathServlet est� registrado impl�citamente y est� disponible desde cualquier aplicaci�n.

Hay dos formas en las que podemos usar ClasspathServlet:

• Para servir un recurso desde el CLASSPATH del sistema, llamamos al recurso con una URL como esta:

  http://server:port/classes/my/resource/myClass.class
  

• Para servir un recurso desde el directorio WEB-INF/classes de una aplicaci�n Web, llamamos al recurso con una URL como esta:

  http://server:port/myWebApp/classes/my/resource/myClass.class
  

  En este caso, el recurso est� localizado en el siguiente directorio, en relaci�n a la ra�z de la aplicaci�n Web:

  WEB-INF/classes/my/resource/myClass.class
  

�Pasar Peticiones a otro Servidor WebLogic

Cuando usamos WebLogic Server como nuestro servidor Web principal, tambi�n podr�amos querer configurarlo para pasar (actuar como proxy) ciertas peticiones a un servidor HTTP secundario, como Netscape Enterprise Server, Apache, o Microsoft Internet Information Server. Cualquier petici�n proxy es redirigida a una URL espec�fica. Incluso podemos pasarla a otro servidor Web en una m�quina diferente. Nuestras peticiones proxy se basan en la URL de la petici�n entrante.

El HttpProxyServlet (proporcionado como parte de la distribuci�n) toma una petici�n HTTP, la redirige a la URL proxy, y env�a la respuesta de vuelta al cliente a trav�s del Servidor WebLogic. Para usar el proxy, debemos configurarlo en una Aplicaci�n Web y desplegar esa Aplicaci�n Web sobre el Servidor WebLogic que est� redirigiendo las peticiones.

�Seleccionar un Proxy a un Servidor HTTP Secundario

Para seleccionar un proxy a un servidor HTTP secundario:

1. Registramos el servlet proxy en nuestro descriptor de despliegue de Aplicaci�n Web (ver Ejemplo de web.xml para usar con ProxyServlet). La aplicaci�n Web debe ser la Aplicaci�n Web por defecto del servidor que est� respondiendo a las peticiones. El nombre de la clase para el servlet proxy es weblogic.t3.srvr.HttpProxyServlet.
2. Definimos un par�metro de inicializaci�n para el ProxyServlet con un <param-name> de redirectURL y un <param-value> que contenga la URL del servidor al que se deber�an pasar las peticiones.
3. Mapeamos el ProxyServlet a un <url-pattern>. Especificamente, mapeamos las extensiones de ficheros que deseamos pasar (proxy), por ejemplo *.jsp,o *.html. Usamos el elemento <servlet-mapping> en el descriptor de despliegue de la Aplicaci�n Web.

   Si seleccionamos <url-pattern> a �/�, entonces cualquier petici�n que no pueda ser resuelta por el Servidor WebLogic ser� pasara al servidor remoto. Sin embargo, tambi�n debemos mapear espec�ficamente las extensiones *.jsp, *.html, y *.html si queremos pasar los ficheros que terminan en estas extensiones.

4. Desplegamos la Aplicaci�n en el Servidor WebLogic que redirige las peticiones entrantes.

�Ejemplo de web.xml para usar con ProxyServlet

Lo siguiente es un ejemplo de un descriptor de despliegue de una Aplicaci�n Web para usar el ProxyServlet:

<!-- DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 1.2//EN"
"file:///weblogic/dev/myserver/servlet2.2/WEB-INF/web-jar.dtd"
-->
<web-app>

<servlet>
  <servlet-name>ProxyServlet</servlet-name>
  <servlet-class>weblogic.t3.srvr.HttpProxyServlet</servlet-class>
    <init-param>
      <param-name>redirectURL</param-name>
      <param-value>
        tehama1:7736:7737|tehama2:7736:7737|tehama:7736:7737
      </param-value>
    </init-param>
</servlet>

<servlet-mapping>
  <servlet-name>ProxyServlet</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>ProxyServlet</servlet-name>
  <url-pattern>*.jsp</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>ProxyServlet</servlet-name>
  <url-pattern>*.htm</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>ProxyServlet</servlet-name>
  <url-pattern>*.html</url-pattern>
</servlet-mapping>

</web-app>

�Pasar Peticiones (proxy) a un Cluster WebLogic

El HttpClusterServlet (proporcionado con la distribuci�n de WebLogic Server) pasa peticiones desde un servidor WebLogic a otros servidores WebLogic en un Cluster WebLogic. HttpClusterServlet proporciona balance de carga y proteci�n de fallos para las peticiones HTTP pasadas.

�Configurar el HttpClusterServlet

Para configurar el HttpClusterServlet:

1. Configuramos el ejemplar de WebLogic Server que pasar� las peticiones a un cluster de servidores WebLogic. Usamos la Consola de Administraci�n:
   • Creamos una nueva Aplicaci�n Web en nuestro dominio.
   • Creamos un nuevo Servidor en el dominio, o usamos el servidor por defecto.
   • Asignamos la aplicaci�n Web que hemos creado como la aplicaci�n Web por defecto para el servidor que acabamos de crear.
2. Registramos el HttpClusterServlet en el descriptor de despliegue de la aplicaci�n Web que hemos ceado (puedes ver un ejemplo en Ejemplo de Descriptor de Despliegue para el HttpClusterServlet). La Aplicaci�n Web debe ser la aplicaci�n web por defecto del servidor que est� respondiendo a las peticiones. Puedes encontrar m�s informaci�n en Designar una Aplicaci�n Web por Defecto.

   El nombre de la clase para HttpClusterServlet es weblogic.servlet.internal.HttpClusterServlet.

3. Definimos los par�metros de inicializaci�n apropiados para HttpClusterServlet. Los definimos con el elemento <init-param> en el descriptor de despliegue de la aplicaci�n Web. Debemos definir el par�metro defaultServers, y, cuando sea apropiado, los par�metros adicionales seg�n se definen en la siguiente tabla.
4. Mapeamos el Proxy Servlet a un <url-pattern>. Especificamente, mapeamos las extensiones de ficheros que deseamos pasar (proxy), por ejemplo *.jsp,o *.html. Usamos el elemento <servlet-mapping> en el descriptor de despliegue de la Aplicaci�n Web.

   Si seleccionamos <url-pattern> a �/�, entonces cualquier petici�n que no pueda ser resuelta por el Servidor WebLogic ser� pasada al servidor remoto. Sin embargo, tambi�n debemos mapear espec�ficamente las extensiones *.jsp, *.html, y *.html si queremos pasar los ficheros que terminan en estas extensiones.

Otra forma de configurar el url-pattern es mapear un url-pattern como /foo y luego configurar el par�metro pathTrim como foo, lo que elimina foo de la URL pasada (proxy).

host1:HTTP_Port:HTTPS_Port|
host2:HTTP_Port:HTTPS_Port

�Ejemplo de Descriptor de Despliegue para HttpClusterServlet

Lo siguiente es un ejemplo de un descriptor de despliegue de una Aplicaci�n Web para usar el HttpClusterServlet:

<!-- DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 1.2//EN"
"file:///weblogic/dev/myserver/servlet2.2/WEB-INF/web-jar.dtd"
-->

<web-app>

<servlet>
  <servlet-name>HttpClusterServlet</servlet-name>
    <servlet-class>
      weblogic.servlet.internal.HttpClusterServlet
    </servlet-class>

  <init-param>
    <param-name>defaultServers</param-name>
    <param-value>
      myserver1:7736:7737|myserver2:7736:7737|myserver:7736:7737
    </param-value>
  </init-param>

  <init-param>
    <param-name>DebugConfigInfo</param-name>
    <param-value>ON</param-value>
  </init-param>
</servlet>

<servlet-mapping>
  <servlet-name>HttpClusterServlet</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>HttpClusterServlet</servlet-name>
  <url-pattern>*.jsp</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>HttpClusterServlet</servlet-name>
  <url-pattern>*.htm</url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>HttpClusterServlet</servlet-name>
  <url-pattern>*.html</url-pattern>
</servlet-mapping>

</web-app>

�Configuar la Seguridad en Aplicaciones Web

Podemos asegurar una Aplicaci�n Web usando autentificaci�n, mediante la restricci�n de acceso a ciertos recursos en la Aplicaci�n Web, o usando llamadas de seguridad a nuestro c�digo Servlet. Se pueden usar varios reinos de seguridad.

�Configurar la Autentificaci�n para Aplicaciones Web

Definimos la autentificaci�n para Aplicaciones Web en el descriptor de despliegue de la Aplicaci�n Web, usando el elemento <login-config>. En este elemento definimos los reinos de seguridad conteniendo credenciales de usuario, el m�todo de autentificaci�n, y la localizaci�n de los recursos para autentificaci�n.

Para configurar la autentificaci�n para Aplicaciones Web:

1. Elegimos el m�todo de autentificaci�n. Las opciones disponibles son:
   • BASIC
     Esta autentificaci�n usa el navegador web para mostrar una caja de di�logo username/password. Estos valores se autentifican contra el reino.
   • FORM
     La autentificaci�n basada en formulario requiere que devolvamos un formulario HTML que contenga el nombre de usuario y la password. Los campos devueltos por los elementos del formularo deben ser: j_username y j_password, y el atributo action debe ser j_security_check. Aqu� hay un ejemplo de c�digo HTML para usar la autentificaci�n FORM:

     
     <form method=�POST� action=�j_security_check�>
     <input type=�text� name=�j_username�>
     <input type=�password� name=�j_password�>
     </form>
     
     	

     El recurso usado para generar el formulario HTML podr�a ser una p�gina HTML, un JSP o un Servlet. Definimos este recurso con el elemento <form-login-page>.

     El objeto sesi�n HTTP se crea cuando se sirve la p�gina log�n. Por lo tanto, el m�todo session.isNew() devolver� FALSE cuando se llame desde p�ginas servidas despu�s de que la autentificaci�n tenga �xito.

   • CLIENT-CERT
     Usa certificados de cliente para autentificar la petici�n.
2. Si elegimos la autentificaci�n FORM, tambi�n definimos la localizaci�n de los recursos usados para generar una p�gina HTML y un recurso que responda a una autentificaci�n fallida.
3. Definimos el reino usado para autentificaci�n. Si no especificamos un reino particular, se usar� el reino definido con el campo Auth Realm Name en la pesta�a Web Application --> Configuration --> Other de la Consola de Adminsitraci�n.

�M�ltiples Aplicaciones Web, Cookies y Autentificaci�n

Por defecto, WebLogic Server asigna el mismo nombre de cookie (JSESSIONID) para todas las aplicaciones Web. Cuando usamos cualquier tipo de autentificaci�n, todas las aplicaciones Web que usan el mismo nombre de cookie usan una s�la firma para autentificaci�n. Una vez que un usuario se ha autentificado, esa autentificaci�n ser� v�lida para peticiones de cualquier aplicaci�n Web que use el mismo nombre de cookie. No se le pedir� al usuario que vuelva a autentificarse.

Si queremos requerir autentificaci�n separada para una Aplicaci�n Web, podemos especificar un nombre de cookie distinto para la Aplicaci�n Web. Podemos hacer esto usando el par�metro CookieName, definido en el descriptor de despliegue espec�fico de WebLogic, weblogic.xml, en el elemento <session-descriptor>.

�Restringir el Acceso a Recursos de una Aplicaci�n Web

Podemos aplicar restricciones a recursos espec�ficos (servlets, JSPs, o p�ginas HTML) de nuestra aplicaci�n Web. Para aplicar restricciones de seguridad:

1. Definimos un rol que es mapeado a uno o m�s principales en un reino de seguridad. Definimos los roles con el elemento <security-role> en el descriptor de despliegue de la Aplicaci�n Web. Entonces mapeamos esos roles a los principales en nuestro reino con el elemento <security-role-assignment> en el descriptor de despliegue espec�fico de WebLogic.
2. Definimos a qu� recursos de la aplicaci�n Web se aplican las restricciones usando el elemento <url-pattern> que est� anidado dentro del elemento <web-resource-collection>. El <url-pattern> puede referirse a un directorio, un nombre de fichero o a un <servlet-mapping>.
   Para aplicacar las restricciones de seguridad a toda la aplicaci�n Web, usamos el siguiente <url-pattern>:

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

3. Definimos el m�todo HTTP (GET o POST) a los que se aplican las restricciones usando el elemento <http-method> que est� anidado dentro del elemento <web-resource-collection>.
4. Definimos si se deber�a usar o no SSL para las comunicaciones entre el cliente y el servidor usando el elemento <transport-guarantee> que est� anidado dentro del m�todo <user-data-constraint>.

C�digo de ejemplo:

Entradas en web.xml:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>SecureOrdersEast</web-resource-name>
      <description>
        Security constraint for resources in the orders/east directory
      </description>

    <url-pattern>/orders/east/*</url-pattern>
    <http-method>POST</http-method>
    <http-method>GET</http-method>
  </web-resource-collection>

  <auth-constraint>
    <description>constraint for east coast sales</description>
    <role-name>east</role-name>
    <role-name>manager</role-name>
  </auth-constraint>

  <user-data-constraint>
    <description>SSL not required</description>
    <transport-guarantee>NONE</transport-guarantee>
  </user-data-constraint>

</security-constraint>

...

<security-role>
  <description>east coast sales</description>
  <role-name>east</role-name>
</security-role>

<security-role>
  <description>managers</description>
  <role-name>manager</role-name>
</security-role>

Entradas en weblogic.xml:

<security-role-assignment>
  <role-name>east</role-name>
  <principal-name>tom</principal-name>
  <principal-name>jane</principal-name>
  <principal-name>javier</principal-name>
  <principal-name>maria</principal-name>
</security-role-assignment>

<security-role-assignment>
  <role-name> manager </role-name>
  <principal-name>peter</principal-name>
  <principal-name>georgia</principal-name>
</security-role-assignment>

�Usar Usuarios y Roles Program�ticamente en Servlets

Podemos escribir nuestros servlets para acceder program�ticamente a usuarios y roles en nuestro c�digo de servlet usando el m�todo javax.servlet.http.HttpServletRequest.isUserInRole(String role).

El string role es mapeado al nombre suministrado en el elemento <role-name> que est� anidado dentro del elemento <security-role-ref> de una declaraci�n <servlet> en el descriptor de despliegue de la aplicaci�n. El elemento <role-link> se mapea a un <role-name> definido en el elemento <security-role> del descriptor de despliegue de la aplicaci�n Web.

Por ejemplo:

C�digo Servlet:

isUserInRole("manager");


Entradas en web.xml:

<servlet>
...
  <role-name>manager</role-name>
  <role-link>mgr</role-link>
...
</servlet>

<security-role>
  <role-name>mgr</role-name>
</security-role>

Entradas en weblogic.xml:

<security-role-assignment>
  <role-name>mgr</role-name>
  <principal-name>al</principal-name>
  <principal-name>george</principal-name>
  <principal-name>ralph</principal-name>
</security-role-ref>

�Configurar Recursos Externos de una Aplicaci�n Web

Cuando accedemos a recursos externos, como una DataSource desde una Aplicaci�n Web mediante JNDI, podemos mapear el nombre JNDI que buscamos en nuestro c�digo al nombre JNDI real unido en el �rbol JNDI. Este mapeo se hace usando los dos descriptores de despliegue web.xml y weblogic.xml y nos permite cambiar estos recursos sin tener que modificar el c�digo de nuestra aplicaci�n. Proporcionamos un nombre que se usa en nuestro c�digo Java, el nombre del recurso que est� unido al �rbol JNDI, y el tipo Java del recurso, e indicamos si la seguridad del recurso se maneja program�ticamente por el servlet o desde las credenciales asociadas con la petici�n HTTP.

Para configurar recursos externos:

1. Introducimos el nombre del recurso en el descriptor de despliegue seg�n lo usamos en nuestro c�gido, el tipo Java, y el tipo de autorizaci�n de seguridad.
2. Mapeamos el nombre del recurso al nombre JNDI.

El siguiente ejemplo asume que hemos definido una fuente de datos llamada accountDataSource:

C�digo del Servlet:

javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup
  ("myDataSource");

Entradas en web.xml:

<resource-ref>
  ...
  <res-ref-name>myDataSource</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>CONTAINER</res-auth>
  ...
</resource-ref>

Entradas en weblogic.xml:

<resource-description>
  <res-ref-name>myDataSource</res-ref-name>
  <jndi-name>accountDataSource</jndi-name>
</resource-description>

�Referenciar EJBs en una Aplicaci�n Web

Referenciamos EJBs en una aplicaci�n Web d�ndoles un nombre en el descriptor de despliegue de la aplicaci�n Web que es mapeado al nombre JNDI para el EJB que est� definido en el fichero descriptor de despliegue weblogic-ejb-jar.xml.

Para configurar EJBs para usarlos en una Aplicaci�n Web:

1. Introducimos el nombre de referencia del EJB que usamos para buscar el EJB en nuestro c�digo, el nombre de la clase Java de los interfaces home y remoto del EJB en el elemento <ejb-ref> del descriptor de despliegue de la Aplicaci�n Web.
2. Mapeamos el nombre de referencia en el elemento <ejb-reference-description> del descriptor de despliegue espec�fico de WebLogic, weblogic.xml, al nombre JNDI definido en el fichero weblogic-ejb-jar.xml.

Si la Aplicaci�n Web es parte de un Enterprise Application Archive (fichero *.ear), podemos referenciar un EJB por el nombre usado en el .ear con el elemento <ejb-link>.

�Configurar el Manejo de Sesi�n

WebLogic Server est� configurado para manejar el seguimiento de sesi�n por defecto. No necesitamos configurar ninguna de estas propiedades para usar seguimiento de sesi�n. Sin embargo, configurar el modo en que WebLogic Server maneja las sesiones es una parte importante del ajuste de nuestra aplicaci�n para un mejor rendimiento.

El ajuste depende de factores como:

• Cu�ntos usuarios esperamos que usen el servlet.
• Cuantos usuarios concurrentes esperamos que usen el servlet.
• Cu�nto durar� cada sesi�n.
• Cu�ntos datos esperamos que se almacenen por cada usuario.

�Propiedades de Sesi�n HTTP

Configuramos WebLogic Server para que haga seguimiento de sesi�n con las propiedades del descriptor de despliegue espec�fico de WebLogic, weblogic.xml.

Puedes encontrar una lista completa de atributos de sesi�n en http://e-docs.bea.com/wls/docs60/programming/weblogic_xml.html#session-descriptor.

�TimeOut de Sesi�n

Podemos especificar un intervalo de tiempo despu�s del cual expiran las sesiones HTTP. Cuando una sesi�n expira, todos los datos almacenados en la sesi�n son descartados. Podemos seleccionar el intervalo de una de estas formas:

• Seleccionando el atributo TimeoutSecs del elemento <session-descriptor> de descriptor de despliegue espec�fico de WebLogic. Este valor es en segundos.
• Seleccionando el elemento <session-timeout> en el descriptor de despliegue de la aplicaci�n Web. Este valor se selecciona en segundos y sobreescribe cualquier valor que pongamos en el atributo TimeoutSecs.

�Configurar Cookies de Sesi�n

WebLogic Server usa cookies para manejo de sesiones cuando lo soporta el navegador del cliente.

Las cookies que usa WebLogic Server para seguir la sesi�n son temporales por defecto y no sobreviven a la vida del navegador. Cuando un usuario cierra su navegador, las cookies se pierden y se acaba el tiempo de la sesi�n. Este comportamiento est� en el espiritu del uso de la sesi�n y se recomienda que usemos las sesiones de esta forma.

Es posible configurar muchos aspectos de las cookies usadas para seguimiento de sesi�n con atributos definidos en el descriptor de despliegue espec�fico de WebLogic. Puedes encontrar una lista completa de atributos relacionados con la sesi�n y las cookies en http://e-docs.bea.com/wls/docs60/programming/weblogic_xml.html#session-descriptor.

�Usar Cookies de Larga Vida

Para datos de usuario de larga vida en el lado del cliente, nuestra aplicaci�n deber�a crear y configurar sus propias cookies en el navegador mediante el API servlet HTTP, y no deber�amos intentar usar las cookies asociadas con la sesi�n HTTP. Nuestra aplicaci�n podr�a usar cookies para auto-login un usuairo desde una m�quina particular, en cuyo caso configurar�amos una nueva cookie con un largo tiempo de caducidad. Recuerda que la cookie s�lo puede ser enviada desde la m�quina del cliente. Nuestra aplicaci�n deber�a almacenar los datos en el servidor si debe ser accedida por el usuario desde m�ltiples localizaciones.

No podemos conectar directamente la edad de un cookie de navegador con la longitud de una sesi�n. Si una cookie expira antes de su sesi�n asociada, esta sesi�n se vuelve huerfana. Si una sesi�n expira antes que su cookie asociada, el servler no podr� encontrar una sesi�n. En este punto, se asinga una sesi�n cuando se llama al m�todo getSession(). S�lo deber�amos hacer un uso temporal de las sesiones.

�Configurar la Persistencia de Sesi�n

Hay cuatro diferentes implementaciones de persistencia de sesi�n:

• Memoria (un-s�lo-servidor, no-replicado)
• Persistencia de sistema de Ficheros
• Persistencia JDBC
• Replicaci�n en memoria (en un cluster).

Las tres primeras se cubren aqu�; la replicaci�n en memoria se cubre en http://e-docs.bea.com/wls/docs60/cluster/servlet.html.

Para la replicaci�n en memoria, fichero, y JDBC, necesitamos configurar atributos adicionales, incluyendo PersistentStoreType. Cada m�todo tiene su propio conjunto de propiedades mostradas abajo:

�Propiedades Comunes

Podemos configurar el n�mero de sesiones que mantenemos en memoria configurando los siguientes atributos en el descriptor de despliegue espec�fico de WebLogic. Estos atributos s�lo s�n aplicables si est�mos usando persistencia de sesi�n:

• CacheSize
  Limita el n�mero de sesiones almacenadas que pueden estar activas en memoria en un momento dado. Si estamos esperando un alto volumen de sesiones simult�neas activas, no querremos que estas sesiones bloqueen la RAM de nuestro servidor ya que esto podr�a causar problemas de rendimiento con el intercambio en memoria virtual. Cuando el cach� est� lleno, las �ltimas sesiones m�s recientemente utilizadas se almacenan en el almacen persistente y son llamadas cuando se necesitan. Si no se usa persistencia, esta propiedad es ignorada, y no hay l�mite software en el n�mero de sesiones permitidas en la memoria principal. Por defecto, el n�mero de sesiones cacheadas es 1024. El m�nimo es 16, y el m�ximo es Integer.MAX_VALUE. Una sesi�n vac�a ocupa menos de 100 bytes, pero crece seg�n se van a�adiendo datos.
• SwapIntervalSecs
  El intervalo de tiempo que espera el servidor entre la purga de las sesiones recientemente usadas del cache al almacenamiento persistente, cuando se ha alcanzado el l�mite cacheEntries.
  Si no se configura, esta propiedad tiene un valor por defecto de 10 segunos; el m�nimo es 1 segundo, y el m�ximo 604800 (1 semana).
• InvalidationIntervalSecs
  Selecciona el tiempo, en segundos, que el Servidor WebLogic espera entre hacer el chequeo de limpieza de sesiones time-out o inv�lidas, y el borrado de las viejas sesiones y la liberaci�n de memoria. Seleccionamos este par�metro a un valor menor que el valor del elemento <session-timeout>. Usamos este par�metro para ajustar el Servidor WebLogic para un mejor rendimiento en sites de gran tr�fico.
  El valor m�nimo es cada segundo (1). El valor m�ximo es una vez a la semana (604.800 segundos). Si no se configura, el valor por defecto es 60 segundos.

�Usar Persistencia Basada en Memoria en un S�lo Servidor y no Replicada

Para usar este tipo de persistencia, seleccionamos la propiedad PersistentStoreType a memory. Cuando usamos el almacenamiento basado en memoria toda la informaci�n de sesi�n se almacena en memoria y se pierde cuando paramos e reiniciamos el Servidor WebLogic.

�Usar Persisentica Basada en Fichero

Para el almacenamiento de sesiones basado en ficheros persistentes:

1. Seleccionamos PersistentStoreType a file.
2. Seleccionamos el directorio donde WebLogic Server almacena las sesiones.

   Si no seleccionamos expl�citamente un valor para este atributo, autom�ticamente se crea un directorio temporal en el Servidor WebLogic.

   Si est�mos usando la persitencia basada en ficheros en un cluster, debemos seelccionar expl�citamente este par�metro a un directorio compartido que sea accesible por todos los servidores del cluster. Debemos crear el directorio nosotros mismos.

�Usar Persistencia Basada en Bases de Datos

Para almacenamiento de persistencia de sesiones basado en JDBC:

1. Seleccionamos JDB como el m�todo de almacenamiento de persistencia seleccionando el atributo PersistentStoreType a jdbc.
2. Seleccionamos el almacen de conexiones JDBC a utilizar para el almacenamiento persistente con el atributo PersistentStorePool. Usamos el nombre del almacen de conexioness que est� definido en la Consola de Administraci�n del Servidor WebLogic.
3. Seleccionamos un ACL para la conexi�n que corresponda con los usuarios que tienen permiso.
4. Configuramos una tabla de base de datos llamada wl_servlet_sessions para persistencia basada en JDBC. El almacen de conexiones que conecta con la base de datos necesita tener acceso de lectura/escritura para esta tabla. La siguiente tabla muestra los nombres de columnas y tipos de datos que deber�amos usar para crear esta tabla:

   Nombre de Columna	Tipo
   wl_id	Alfanum�rico de anchura variable, hasta 100 caracteres, por ejemplo, Oracle VARCHAR2(100). La clave primaria debe configurarse como: wl_id + wl_context_path
   wl_context_path	Alfanum�rica de anchura variable, hasta 100 caracteres, por ejemplo, Oracle VARCHAR2(100). Esta columna se usa como parte de la clave primaria.
   wl_is_new	Single char; Por ejemplo, Oracle CHAR(1)
   wl_create_time	Num�rico, 20 digitos; Por ejemplo Oracle NUMBER(20)
   wl_is_valid	Single char; por ejemplo, Oracle CHAR(1)
   wl_session_values	Large binary; Por ejemplo, Oracle LONG RAW
   wl_access_time	Num�rico, 20 digitos; por ejemplo, NUMBER(20)
   wl_max_inactive_interval	Integer; por ejemplo, Oracle Integer. N�mero de sesiones entre peticiones de cliente antes de que la sesi�n sea invalidada. Un valor negativo indica que la sesi�n nunca ser� timeout.

Si estamos usando una base de datos Oracle, podemos usar la siguiente sentencia SQL para crear la tabla wl_servlet_sessions:

create table wl_servlet_sessions
  ( 
    wl_id VARCHAR2(100) NOT NULL,
    wl_context_path VARCHAR2(100) NOT NULL,
    wl_is_new CHAR(1),
    wl_create_time NUMBER(20),
    wl_is_valid CHAR(1),
    wl_session_values LONG RAW,
    wl_access_time NUMBER(20),
    wl_max_inactive_interval INTEGER,
  PRIMARY KEY (wl_id, wl_context_path) );

Podemos modificar la sentencia SQL anterior para usarla con nuestro motor de Base de Datos.

�Usar Reescritura de URL

En algunas ocasiones, un navegador podr�a no aceptar cookies, lo que hace imposible el seguimiento de sesi�n utilizando cookies. La reescritura de URL es una soluci�n a esta situaci�n que puede ser sustituida autom�ticamente cuando el Servidor WebLogic detecta que el navegador no soporta cookies. La reescritura de URL implica la codificaci�n de la ID de la sesi�n en los hiper-enlaces de las p�ginas web que nuestro servlet devuelve al navegador. Cuando luego el usuario pulsa sobre estos enlaces, el Servidor WebLogic extrae la ID de la direcci�n URL y encuentra la HttpSession apropiada cuando nuestro servlet llama al m�todo getSession().

Para activar la reescritura de URLs en el Servidor WebLogic, seleccionamos el atributo URLRewritingEnabled en el descriptor de despliegue espec�fico de WebLogic, bajo el elemento <session-descriptor> a TRUE. (El valor por defecto de este atributo es TRUE).

�Guias de Codificaci�n para Reescritura de URLs

Hay algunas gu�as generales para el modo en que nuestro c�digo deber�a manejar las URLs para soportar la reescritura de URLs:

• Evitar reescribir una URL directamente en el stream de salida, como se muestra aqu�:

  
  out.println("<a href=\"/myshop/catalog.jsp\">catalog</a>");
  
  

  En su lugar, usamos el m�todo HttpServletResponse.encodeURL(), por ejemplo:

  
  out.println("<a href=\"�
     + response.encodeURL(�myshop/catalog.jsp�)
     + �\">catalog</a>");
  
  

  Llamar al m�todo encodeURL() determina si la URL necesita ser reescrita, y si es as�, la reescribe, incluyendo el ID de sesi�n en la URL. El ID de sesi�n se a�ade a la URL y empieza con un punto y coma.
• Adem�s de las URLs que son devueltas como una respuesta al Servidor WebLogic, tambi�n codificamos las URLs que env�an redirecciones. Por ejemplo:

  if (session.isNew())
     response.sendRedirect
  (response.encodeRedirectUrl(welcomeURL));
  

  WebLogic Server usa reescritura de URL cuando una sesi�n es nueva, incluso si el navegador acepta cookies, porque el servidor no puede decir si el navegador acepta cookies en la primera visita de una sesi�n.
• Nuestro servlet puede determinar si una ID de sesi�n dada fue recibida desde una cookie chequeando el Boolean devuelto por el m�todo HttpServletRequest.isRequestedSessionIdFromCookie(). Nuestra aplicaci�n podr�a responder apropiadamente, o simplemente relegar en la reescritura de URL del Servidor WebLogic.

�Reescritura de URL y Wireless Access Protocol (WAP)

Si estamos escribiendo una aplicaci�n Wap, debemos usar la reescritura de URL porque el protocolo WAP no soporta cookies. Adem�s, algunos dispositivos WAP tienen un l�mite de 128 caracteres en la longitud de la URL (incluyendo par�metros), lo que limita la cantidad de datos que se pueden transmitir usando reescritura de URL. Para permitir m�s espacio para los par�metros, podemos l�mitar el tama�o de la ID de sesi�n que genera aleatoriamente el Servidor WebLogic especificando el n�mero de l�mites con el atributo IDLength

�Usar Conjuntos de Caracteres y Datos POST

Podemos seleccionar el conjunto de caracteres que se usa para procesar los datos desde un formulario que usa el m�todo POST. Para informar a la aplicaci�n que procesa los datos del formulario que se est� usando un conjunto de caracteres particular debemos a�adir caracteres especificos "se�ales" a la URL usada para procesar los datos del formulario (especificado con el atributo action de ls etiqueta <form>) y luego mapear dichos caracteres a una codificaci�n en el descriptor de despliegue de la Aplicaci�n Web. Los datos POST normalmente se leen usando ASCII a menos que especifiquemos lo contrario usando el siguiente procedimiento.

Para procesar los datos POST en un conjunto de caracteres no ASCII:

1. Creamos una nueva entrada en el descriptor de despliegue de la Aplicaci�n Web: web.xml, dentro de un elemento <context-param>. Est� entrada deber�a ir despu�s del elemento <distributable> y antes del elemento <servlet> en el fichero web.xml. En esta entrada, el <param-name> siempre incluye el nombre de la clase weblogic.httpd.inputCharset, seguido por un punto, seguido por el string de se�al. El <param-value> contiene el nombre del conjunto de caracteres HTTP. En el siguiente ejemplo, el string /rus/jo* se mapea al conjunto de caracteres windows-1251:

   
   <context-param>
   <param-name>weblogic.httpd.inputCharset./rus/jo*</param-name>
   <param-value>windows-1251</param-value>
   </context-param>
   
   

2. Codificamos el formulario HTML para usar el string de se�al cuando env�e los datos del formulario. Por ejemplo:

   
   <form action="http://some.host.com/myWebApp/rus/jo/index.html">
   ...
   </form>
   
   

   Situamos el string de se�al despu�s del nombre de la aplicaci�n Web (tambi�n llamado path de contexto �myWebApp� en este caso) y antes de la porci�n de renombrado de la URL.