BEA WebLogic: Guía de Administración

• Instalar y Configurar el Plug-In para el Netscape Enterprise Server (NSAPI)
• Introducción al Plug-In para el Netscape Enterprise Server (NSAPI)
• Almacen de Conexiones y Keep-Alive
• Pasar (proxy) Peticiones
• Instalar el Plug-In para Netscape Enterprise Server
• Modificar el Fichero obj.conf
• Usar SSL con el Plug-In de NSAPI
• Errores de Conexión y Control de Fallos en Clustering
• Fallos de Conexión
• Control de Fallos con un Sólo Servidor (sin cluster)
• La Lista de Servidores Dinámica
• Control de Fallos, Cookies y Sesiones HTTP
• Comportamiento Contra Fallos Cuando se usan Firewalls y Directores de Carga
• Ejemplo de fichero obj.conf (sin usar cluster WebLogic)
• Ejemplo de fichero obj.conf (usando un cluster WebLogic)

Instalar y Configurar el Plug-In para el Netscape Enterprise Server (NSAPI)

 Introducción al Plug-In para el Netscape Enterprise Server (NSAPI)

El Plug-In de Netscape Enterprise Server pemite que las peticiones sean pasadas desde Netscape Enterprise Server (NES, también llamado iPlanet) hacia el servidor WebLogic.

El plug-in se ha pensado para un entorno en el que un Servidor Netscape Enterprise sirve páginas estáticas, y otra parte del árbol de documentos (páginas dinámicas mejor generadas por Servlets HTTP o JavaServer Pages) se delega en el Servidor WebLogic, que podría estar operando en un proceso diferente, posiblemente en un host diferente. Las conexiones entre el Servidor WebLogic y el Plug-In de Netscape Enterprise Server se realizan usando texto claro o Secure Sockets Layer (SSL). En el usuario final -- el navegador -- las peticiones HTTP delegadas al Servidor WebLogic parecerán que vienen de la misma fuente.

El tunneling HTTP también puede operar a través del plug-in, proporcionando acceso a los servicios WebLogic a los clientes que no sean navegadores.

El Plug-In Netscape Enterprise Server Plug-In opera como un módulo NSAPI (ver http://home.netscape.com/servers/index.html) dentro de un servidor Netscape Enterprise Server. El módulo NSAPI lo carga NES en la arrancada, y luego se le delegan ciertas peticiones. NSAPI es similar a un servlet HTTP (Java), excepto en que NSAPI está escrito en el código nativo de la plataforma.

Para más información sobre las versiones de los servidores Netscape Enterprise Server e iPlanet soportadas, puedes ver la página http://e-docs.bea.com/wls/platforms/index.html#plugin.

 Almacen de Conexiones y Keep-Alive

El Plug-In WebLogic Server NSAPI proporciona eficiencia de rendimiento usando un almacen de conexiones re-utilizables desde el plug-in hacia el servidor WebLogic. El plug-in NSAPI implementa automáticamente conexiones keep-alive entre el plug-in y el servidor WebLogic. Si una conexión está inactiva durante más de 30 segundo, o un valor definido por el usuario, la conexión se cierra.

 Pasar (proxy) Peticiones

El Plug-In pasa peticiones al servidor WebLogic basándose en una configuración que nosotros específicamos. Podemos pasar peticiones basándonos en la URL de la peticiones (o en una porción de la URL). Esto se llama proxy por path. También podemos pasar peticones basándonos en el tipo MIME del fichero solicitado. También podemos usar una combinación de ámbos métodos. Si una petición cumple los dos criterios, se pasa por path. También podemos especificar parámetros adicionales para aquellos tipos de peticiones que definen un comportamiento adicional del plug-in.

 Instalar el Plug-In para Netscape Enterprise Server

Para instalar y configurar el Plug-In de Netscape Enterprise Server:

1. Copiar la librería:

   El módulo plug-in NSAPI WebLogic se distribuye como un objeto compartido (.so) sobre plataformas UNIX y como una librería de enlace dinámico (.dll) sobre Windows. Estos ficheros se localizan respectivamente en los directorios /lib o /bin de nuestra dirección del servidor WebLogic.

   Elegimos el fichero de librería apropiada para nuestro entorno desde la página http://e-docs.bea.com/wls/platforms/index.html#plugin y copiamos ese fichero al sistema de ficheros donde está localizado NES.

2. Modificamos el fichero obj.conf. Este fichero define qué peticiones son pasadas al servidor WebLogic y otra información de configuración.
3. Si estamos pasando peticiones por tipo MIME:
   • Añadimos las líneas apropiadas al fichero obj.conf.
   • Añadimos cualquier nuevo tipo MIME referenciado en el fichero obj.conf al fichero MIME.types. Podemos añadir tipos MIME usando la consola del servidor Netscape o editando directamente este fichero.

     Para editar directamente el fichero MIME.types, abrimos el fichero para editarlo y tecleamos la siguiente línea:

     type=text/jsp exts=jsp
     

     Nota: Para NES 4.0 (iPlanet), en lugar de añadir el tipo MIME para JSPs, cambiamos el tipo MIME existente de: magnus-internal/jsp a text/jsp

     Para usar la consola de Netscape, seleccionamos Manage Preferences --> Mime Types, y hacemos las adiciones o ediciones.

4. Desplegamos y probamos el Plug-In de Netscape Enterprise Server:
   • Arrancamos WebLogic Server.
   • Arrancamos Netscape Enterprise Server. Si NES ya está ejecutándose, debemos reiniciar o aplicar las nuevas selecciones desde la consola para que tengan efecto.
   • Para probar el Plug-In de Netscape Enterprise Server, abrimos un navegador y selecccionamos la URL hacia el Enterprise Server + /weblogic/, lo que nos debería traer la página HTML por defecto del servidor WebLogic, la página de bienvnida o el servlet por defecto, según lo definido en la aplicación Web por defecto del Servidor WebLogic, como se muestra en este ejemplo:

     http://myenterprise.server.com/weblogic/
     

 Modificar el Fichero obj.conf

Para usar el Plug-In de Netscape Enterprise Server, debemos hacer varias modificaciones en el fichero obj.conf de NES. Estas modificaciones especifican cómo se pasan las peticiones al servidor WebLogic. Podemos pasar peticones por URL o por tipo MIME. El procedimiento para cada uno se describe más adelante en esta sección. El fichero obj.conf de Netscape es muy estricto en cuanto a la situación del texto. Para evitar problemas, observaremos estos cuidados en el objeto obj.conf :

Eliminar los espacios en blanco al principio y al final. Los espacios en blanco extras pueden hacer que falle nuestro Servidor Nestcape. Si debemos introducir más caracteres de los que caben en una línea, situamos una barra invertida (\) al final de la línea y continuamos tecleado en la siguiente. La barra invertida añade directamente el fin de la primera línea al inicio de la segunda, debemos asegurarnos de no usar ningun espacio, ni al final de la primera línea (antes de la barra invertida), ni al inicio de la segunda línea. No debemos dividir atributos en varias líneas. (por ejemplo, todos los servidores de un cluster deben listarse en la misma línea, siguiendo a WebLogicCluster). Si no existe en la configuración un parámetro requerido, cuando el objeto sea invocado lanzará un error HTML que avisa del parámetro omitido en la configuración.

Para configurar el fichero obj.conf:

1. Localizamos y abrimos obj.conf.

   Este fichero está en la siguiente localización:

   NETSCAPE_HOME/https-INSTANCE_NAME/config/obj.conf
   

   Donde NETSCAPE_HOME es el directorio raíz de la instalación de NES, y INSTANCE_NAME es el ejemplar o configuración particular del servidor que estamos usando. Por ejemplo, en una máquina UNIX, llamada myunixmachine,el fichero obj.conf se encontraría en:

   /usr/local/netscape/enterprise-351/https-myunixmachine/config/obj.conf
   

2. Instruímos a NES para que cargue la librería nativa como un módulo NSAPI.

   Añadimos las siguientes líneas al principio del fichero obj.conf. Estas líneas instruyen a NES para que cargue la librería nativa (el fichero .so o .dll) como un modulo NSAPI:

   Init fn="load-modules" funcs="wl_proxy,wl_init"\
   shlib=/usr/local/netscape/plugins/SHARED_LIBRARY
   Init fn="wl_init"
   

   donde SHARED_LIBRARY es el objeto comparttido o dll (por ejemplo libproxy.so) que hemos instalado en el paso 1 de Instalar y Configurar el Plug-In de Netscape Enterprise Server. La función load-modules etiqueta la librería compartida para cargarla cuando arranque NES. Los valores wl_proxy y wl_init identifican las funciones que ejecuta el Plug-In de Netscape Enterprise Server.

3. Si queremos pasar peticiones por URL, (también llamado paso por path), creamos una etiqueta <Object> separada por cada URL que queramos pasar y definimos el parámetro PathTrim. Pasar por path tiene precedencia sobre el paso por tipo MIME. Lo siguiente es un ejemplo de un etiqueta <Object> que pasa peticiones que contengan el string */weblogic/*:

   
   <Object name="weblogic" ppath="*/weblogic/*">
   Service fn=wl_proxy WebLogicHost=myserver.com\
   WebLogicPort=7001 PathTrim="/weblogic"
   </Object>
   
   

   Para crear una etiqueta <Object> para pasar peticiones por URL:

   • Especificamos un nombre para este objeto (opcional) dentro de la etiqueta <Object> abierta usando el nombre del atributo. Este nombre es sólo informativo y no se usa en el Plug-In de Netscape Enterprise Server. Por ejemplo:

     
     <Object name=myObject ...>
     
     

   • Especificamos la URL a pasar dentro de la etiqueta <Object>, usando el atributo ppath. Por ejemplo:

     
     <Object name=myObject ppath="*/weblogic/*>
     
     

     El valor del atributo ppath puede ser cualquier string que identifique peticiones para el Servidor WebLogic. Cuando usamos ppath, cada petición que contenga ese path será redirigida. Por ejemplo, un ppath de */weblogic/* redirige todas las peticiones que empiecen con http://enterprise.com/weblogic al Plug-In de Netscape Enterprise Server, que envía la petición al host o cluster del WebLogic especificado.

   • Añadimos la directiva Service entre las etiquetas <Object> y </Object>. En esta directiva podemos especificar cualquier parámetro válido como parejas nombre=valor. Separamos los distintos parámetros con un y solo un espacio en blanco. Por ejemplo:

     Service fn=wl_proxy WebLogicHost=myserver.com\
     WebLogicPort=7001 PathTrim="/weblogic"
     

     Debemos especificar los siguientes parámetros:

     • Para un servidor WebLogic sin Cluster:
       WebLogicHost y WebLogicPort.
     • Para un servidor WebLogic con Cluster:
       WebLogicCluster.

     La directiva Service siempre debe empezar con Service fn=wl_proxy, seguido por parejas de parámetros nombre=valor válidas.

     Aquí tenemos un ejemplo de definidiones de objetos para dos ppaths distintos que identifican peticiones que deben ser enviadas a diferentes ejemplares de WebLogic Server:

     
     <Object name="weblogic" ppath="*/weblogic/*">
     Service fn=wl_proxy WebLogicHost=myserver.com\
     WebLogicPort=7001 PathTrim="/weblogic"
     </Object>
     
     <Object name="si" ppath="*/servletimages/*">
     Service fn=wl_proxy WebLogicHost=otherserver.com\
     WebLogicPort=7008
     </Object>
     
     

     Nota: Los parámetros que no son obligatorios, como PathTrim, se pueden usar para configurar la forma en que ppath se pasa a través del Plug-In de Netscape Enterprise Server.

4. Si queremos pasar por tipo MIME, el tipo MIME debe estar listado en el fichero MIME.types. Para ver instrucciones sobre como modificar este fichero puedes ir al paso 3 de Instalar y Configurar el Plug-In de Netscape Enterprise Server.

   Todas las peticiones con una extensión del tipo MIME designado (por ejemplo, .jsp) pueden pasarse al Servidor WebLogic sin importar la URL.

   Para pasar todas las peticiones de un cierto tipo de fichero al Servidor WebLogic:

   • Añadimos una directiva Service a la definición del objeto por defecto (<Object name=default ...>). Por ejemplo, para pasar todas las JSPs a un Servidor WebLogic, deberíamos añadir la siguiente directiva Service después de la última línea que empieza con:

     NameTrans fn=....
     

     y antes de la línea que empieza con:

     PathCheck
     

     Service method="(GET|HEAD|POST|PUT)" type=text/jsp
     fn=wl_proxy\
     WebLogicHost=192.1.1.4 WebLogicPort=7001
     PathPrepend=/jspfiles
     

     Esta directiva pasa todos los ficheros con extensión .jsp al servidor WebLogic designado, donde son servidas con una URL como esta:

     http://WebLogic:7001/jspfiles/myfile.jsp
     

     El valor del parámetro PathPrepend debería corresponder al contexto raíz de una aplicación Web que está desplegada en el Servidor o Cluster WebLogic al que pasamos las peticiones.

     Después de añadir las entradas para el Plug-in del Netscape Enterprise Server, la definición del objeto por defecto debería ser similar a la del siguiente ejemplo:

     
     <Object name=default>
     NameTrans fn=pfx2dir from=/ns-icons\
     dir="c:/Netscape/SuiteSpot/ns-icons"
     NameTrans fn=pfx2dir from=/mc-icons\
     dir="c:/Netscape/SuiteSpot/ns-icons"
     NameTrans fn="pfx2dir" from="/help" dir=\
     "c:/Netscape/SuiteSpot/manual/https/ug"
     NameTrans fn=document-root root="c:/Netscape/SuiteSpot/docs"
     Service method="(GET|HEAD|POST|PUT)" type=text/jsp\
     fn=wl_proxy WebLogicHost=localhost WebLogicPort=7001\
     PathPrepend=/jspfiles
     PathCheck fn=nt-uri-clean
     PathCheck fn="check-acl" acl="default"
     PathCheck fn=find-pathinfo
     PathCheck fn=find-index index-names="index.html,home.html"
     ObjectType fn=type-by-extension
     ObjectType fn=force-type type=text/plain
     Service method=(GET|HEAD) type=magnus-internal/imagemap\
     fn=imagemap
     Service method=(GET|HEAD) \
     type=magnus-internal/directory fn=index-common
     Service method=(GET|HEAD) \
     type=*~magnus-internal/* fn=send-file
     AddLog fn=flex-log name="access"
     </Object>
     
     

   • Añadimos una sentencia Service a la definición del objeto por defecto para todos los otros tipos MIME que queramos pasar al Servidor WevLogic.
5. Si queremos permitir el tunneling-HHTP (opcional):

   Añadimos la siguiente definición de objeto al fichero obj.conf, sustituyendo el nombre del host o cluster WebLogic y el número de puerto por el que deseemos nosotros:

   
   <Object name="tunnel" ppath="*/HTTPClnt*">
   Service fn=wl_proxy WebLogicHost=192.192.1.4\
   WebLogicPort=7001
   </Object>
   
   

 Usar SSL con el Plug-In de NSAPI

Podmos usar el protocolo Secure Sockets Layer (SSL) para proteger la conexión entre el Plug-In de Netscape Enterprise Server, y el Servidor WebLogic. El protocolo SSL proporciona confidencialidad e integridad de los datos pasados entre el Plug-In de Netscape Enterprise Server y el Servidor WebLogic. Además, el protocolo SSL permite al plug-in autenticarse a si mismo en el Servidor WebLogic para asegurar que la información es pasada a un principal seguro.

El Plug-In de Netscape Enterprise Server no usa el protocolo de transporte (http o https) especificado en la petición HTTP (normalmente por el navegador) para determinar si se usa o no el protocolo SSL para proteger los datos de la conexión entre el Plug-In de Netscape Enterprise Server y el Servidor WebLogic.

Para usar el protocolo SSL entre el Plug-In de Netscape Enterprise Server y el Servidor WebLogic:

1. Configuramos el Servidor WebLogic para SSL. (Ver Configurar el Protocolo SSL).
2. Configuramos el puerto de escucha SSL del Servidor WebLogic. (Ver Configurar el Puerto de Escucha).
3. Seleccionamos el parámetro WebLogicPort en la directiva Service al puerto de escucha configurado en el paso 2.
4. Seleccionamos el parámetro SecureProxy en la directiva Service a ON.
5. Seleccionamos cualquier parámetro adicional en la directiva Service que defina información sobre la conexión SSL. Puedes ver una lista completa de parámetros en Parámetros SSL para Plug-Ins de Servidores Web.

 Errores de Conexión y Control de Fallos en Clustering

Cuando el Plug-In de Netscape Enterprise Server intenta conectar con el Servidor WebLogic, usa varios parámetros de configuración para determinar cuánto tiempo esperar las conexiones con el host del Servidor WebLogic y, después de establecida la conexión, cuánto esperar por una respuesta. Si el plug-in no puede conectar o no recibe una respuesta, intentará conectar y envíar la petición a otro Servidor WebLogic del Cluster. Si la conexión falla o no hay respuesta de ningún servidor WebLogic del cluster, se envía un mensaje de error.

 Fallos de Conexión

El fallo de un host al responder a una petición de conexión podría indicar posibles problemas con la máquina host, problemas de red, u otros varios fallos de servidor.

El fallo de un Servidor WebLogic al responder, podría indicar que WebLogic no se está ejecutando que no está disponible, un cuelgue de servidor, un problema de base de datos, u otro fallo de aplicación.

 Control de Fallos con un Sólo Servidor (sin cluster)

Si estámos ejecutando un sólo Servidor WebLogic se aplica la misma lógica descrita aquí, excepto en que el plug-in sólo intenta conectar con el servidor definido en el parámetro WebLogicHost. Si el intento falla, se devuelve un mensaje de error HTTP 503. El plug-in continúa intentando conectar con el Servidor WebLogic hasta que se excede el tiempo ConnectTimeoutSecs.

 La Lista de Servidores Dinámica

Cuando especificamos una lista de servidores WebLogic en el parámetro WebLogicCluster, el plug-in usa esa lista como punto de entrada para el balance de carga entre los miembros del cluster. Después de que se haya enrutado la primera petición a uno de esos servidores, se devuelve una lista dinámica que contiene una lista actualizada con los servidores que hay en el cluster. La lista actualizada añade cualquier nuevo servidor en el cluster y borra cualquier otro que haya dejado de formar parte de él, o que haya fallado al responder peticiones. Esta lista se actualiza automáticamene con la respuesta HTTP cuando ocurre un cambio en el cluster.

 Control de Fallos, Cookies y Sesiones HTTP

Cuando una petición contiene una información de sesión almacenada en un cookie, en los datos POST, o codificando la URL, la ID de la sesión contiene una referencia al servidor específico en que se estableció originalmente la sesión (llamado servidor primario) y una referencia a un servidor adicional donde se ha replicado la sesión original (llamado servidor secundario). Una petición que contiene una cookie intenta conectar con el servidor primario, si el intento falla, la petición se enruta hacia el servidor secundario. Si ambos servidores fallan, la sesión se pierde y el plug-in intenta hacer una nueva conexión con otro servidor de la lista dinámica del cluster. Puedes ver más información en la siguiente figura:

 Comportamiento Contra Fallos Cuando se usan Firewalls y Directores de Carga

En la mayoría de las configuraciones el Plug-In de Netscape Enterprise Server envía peticones a un ejemplar principal de un cluster. Cuando ese ejemplar no está disponible, la petición cae sobre el ejemplar secundario. Sin embargo, en algunas configuraciones que usan combinaciones de firewalls y directores de carga, cualquiera de los servidores (firewalls o director de carga) puede aceptar la petición y devolver una conexión con éxito mientras el ejemplar principal del cluster WebLogic no está disponible. Después de intentar dirigir la petición al ejemplar principal del Servidor WebLogic (que no está disponible), la petición es devuelta al plug-in como un “connection reset”.

La peticiones que se ejecutan a través de combinaciones de firewalls (con o sin directores de carga) son manejadas por el Servidor WebLogic. En otras palabras, responde a una condición de connection reset sobre un ejemplar secundario del Servidor WebLogic.

 Ejemplo de fichero obj.conf (sin usar cluster WebLogic)

Abajo hay un ejemplo de las líneas que se deberían añadir al fichero obj.conf si no estámos usando un cluster. Podemos usar este ejemplo como una plantilla que podemos modificar para que se adapte a nuestro entorno y servidor. Las líneas que empiezan con ’#’ son comentarios.

Nota: Debemos asegurarnos de que no incluimos ningún espacio en blanco extraño en el fichero obj.conf. Al copiar/pegar desde los ejemplos de abajo algunas veces se añaden espacios en blanco extras que pueden crear problemas cuando se lee el fichero.

## ------------- BEGIN SAMPLE OBJ.CONF CONFIGURATION ---------
# (no cluster)
# The following line locates the NSAPI library for loading at
# startup, and identifies which functions within the library are
# NSAPI functions. Verify the path to the library (the value
# of the shlib=<...> parameter) and that the file is
# readable, or the server fails to start.
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/libproxy.so
Init fn="wl_init"
# Configure which types of HTTP requests should be handled by the
# NSAPI module (and, in turn, by WebLogic). This is done
# with one or more "<Object>" tags as shown below.
# Here we configure the NSAPI module to pass requests for
# "/weblogic" to a WebLogic Server listening at port 7001 on
# the host myweblogic.server.com.
<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy WebLogicHost=myweblogic.server.com\
WebLogicPort=7001 PathTrim="/weblogic"
</Object>
# Here we configure the plug-in so that requests that
# match "/servletimages/" is handled by the
# plug-in/WebLogic.
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy WebLogicHost=192.192.1.4 WebLogicPort=7001
</Object>
# This Object directive works by file extension rather than
# request path. To use this configuration, you must also add
# a line to the mime.types file:
#
# type=text/jsp exts=jsp
#
# This configuration means that any file with the extension
# ".jsp" are proxied to WebLogic. Then you must add the
# Service line for this extension to the Object "default",
# which should already exist in your obj.conf file:
<Object name=default>
NameTrans fn=pfx2dir from=/ns-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from=/mc-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn="pfx2dir" from="/help" dir=\
"c:/Netscape/SuiteSpot/manual/https/ug"
NameTrans fn=document-root root="c:/Netscape/SuiteSpot/docs"
Service method="(GET|HEAD|POST|PUT)" type=text/jsp fn=wl_proxy\
WebLogicHost=localhost WebLogicPort=7001 PathPrepend=/jspfiles
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap\
fn=imagemap
Service method=(GET|HEAD) \
type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>
# The following directive enables HTTP-tunneling of the
# WebLogic protocol through the NSAPI plug-in.
<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicHost=192.192.1.4 WebLogicPort=7001
</Object>
#
## ------------- END SAMPLE OBJ.CONF CONFIGURATION ---------

 Ejemplo de fichero obj.conf (usando un cluster WebLogic)

Abajo hay un ejemplo de las líneas que se deberían añadir al fichero obj.conf si estámos usando un cluster. Podemos usar este ejemplo como una plantilla que podemos modificar para que se adapte a nuestro entorno y servidor. Las líneas que empiezan con ’#’ son comentarios.

Nota: Debemos asegurarnos de que no incluimos ningún espacio en blanco extraño en el fichero obj.conf. Al copiar/pegar desde los ejemplos de abajo algunas veces se añaden espacios enn blanco extras que pueden crear problemas cuando se lee el fichero.

## ------------- BEGIN SAMPLE OBJ.CONF CONFIGURATION ---------
# (using a WebLogic Cluster)
#
# The following line locates the NSAPI library for loading at
# startup, and identifies which functions within the library are
# NSAPI functions. Verify the path to the library (the value
# of the shlib=<...> parameter) and that the file is
# readable, or the server fails to start.
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/libproxy.so
Init fn="wl_init"
# Configure which types of HTTP requests should be handled by the
# NSAPI module (and, in turn, by WebLogic). This is done
# with one or more "<Object>" tags as shown below.
# Here we configure the NSAPI module to pass requests for
# "/weblogic" to a cluster of WebLogic Servers.
<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy \
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001" PathTrim="/weblogic"
</Object>
# Here we configure the plug-in so that requests that
# match "/servletimages/" are handled by the
# plug-in/WebLogic.
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy \
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001"
</Object>
# This Object directive works by file extension rather than
# request path. To use this configuration, you must also add
# a line to the mime.types file:
#
# type=text/jsp exts=jsp
#
# This configuration means that any file with the extension
# ".jsp" is proxied to WebLogic. Then you must add the
# Service line for this extension to the Object "default",
# which should already exist in your obj.conf file:
<Object name=default>
NameTrans fn=pfx2dir from=/ns-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from=/mc-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn="pfx2dir" from="/help" dir=\
"c:/Netscape/SuiteSpot/manual/https/ug"
NameTrans fn=document-root root="c:/Netscape/SuiteSpot/docs"
Service method="(GET|HEAD|POST|PUT)" type=text/jsp fn=wl_proxy\
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001",PathPrepend=/jspfiles
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap\
fn=imagemap
Service method=(GET|HEAD) \
type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>
# The following directive enables HTTP-tunneling of the
# WebLogic protocol through the NSAPI plug-in.
<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicCluster="myweblogic.com:7001,\
yourweblogic.com:7001,theirweblogic.com:7001"
</Object>
#
## ------------- END SAMPLE OBJ.CONF CONFIGURATION ---------