Mejora el tráfico de red sobre WebLogic con Canales

El servidor WebLogic cuenta con Canales (Channels) como una alternativa para distribuir el trafico de red, la transferencia de datos de entrada y salida se puede dividir de acuerdo a los requerimientos de volumen de datos de nuestras aplicaciones, para mejorar el rendimiento del sistema, o políticas internas de nuestro departamento de TI.

El uso de Canales no es una mala ni buena práctica que siempre deba estar presente, es una propuesta para la solución y mejora de las condiciones del trafico de la red en la que se encuentra el servidor WebLogic, en este sentido, debe mejorar el rendimiento del sistema.

El procedimiento para crear un Canal desde la Consola de Administración WebLogic es el siguiente:

1. Seleccionar el servidor WebLogic para el cuál se pretende crear el Canal, es decir, aquel servidor sobre el cual están montadas las aplicaciones para las que se desea distribuir el tráfico. 
2. Ir a la pestaña Protocolos y luego seleccionamos la pestaña Canales
3. Creamos el Canal, asignamos el nombre y el protocolo correspondiente:
1. http/https para las aplicaciones Web
2. snmp para conexión con clientes o servidores de administración de Red
3. t3/t3s para conexión con otros servidores WebLogic, etc.
4. Proporcionamos la IP y Puerto por el cual se pretende habilitar el tráfico, puede ser ambos o únicamente el Puerto para trabajar sobre la misma IP.
5. Proporcionamos otros datos dependiente del protocolo seleccionado, normalmente dejar los valores por defecto es suficiente, en casos específicos será necesario establecer los valores exactos.
6. Guardamos y activamos los cambios, comúnmente no es necesario reiniciar.

Un uso común de los Canales se da en ambientes de alta disponibilidad, en donde generamos un Canal exclusivo para la replicación entre los diferentes nodos de un Clúster WebLogic, de igual manera generamos otro Canal dedicado para otra comunicación interna de los nodos.

Cargar librerías externas al CLASSPATH del Servidor WebLogic

El uso de librerías externas para el funcionamiento de las aplicaciones es muy común, para ciertas aplicaciones algunas librerías pueden incluirse en el mismo archivo de despliegue, pero en muchos casos y para otro tipo de aplicaciones es necesario adjuntar estas librerías desde el arranque del servidor WebLogic, esto es, cargar las liberías en el CLASSPATH.

Para aplicaciones Web, por ejemplo, las librerías se pueden incluir en el sub-directorio lib, facilitando el despliegue. Otra opción es el uso de librerías compartidas, que podremos ver otro post.

Usualmente la carga de librerías externas se requiere para aquellas aplicaciones no podemos o no debemos alterar por indicaciones del fabricante, o simplemente no existe una forma de empaquetar tanto la aplicación como las librerías, etc. Ejemplo de estas aplicaciones son: aplicaciones de Oracle SOA Suite, proyectos de Oracle Service Bus, aplicaciones J2EE que utilizan frameworks predefinidos.

Normalmente las librerías se encuentran empaquetadas en archivos JAR (.jar), no obstante también las podemos encontrar como archivos ZIP (.zip). Existen varios métodos para cargar librerías externas en el servidor WebLogic, alguno de estos són:

a) El siguiente método funciona para cualquier librería empaquetada en archivos JAR, todos los servidores WebLogic del dominio cargan las librerías.

1. Colocar las librerías en el directorio lib de nuestro dominio WebLogic. 
2. Reiniciar el servidor WebLogic.

b) Este método nos funciona tanto para archivos JAR como ZIP, todos los servidores WebLogic que para su arranque utilizan el achivo setDomainEnv cargarán las librerías.

1. Abrir en modo edición el archivo setDomainEnv.sh localizado en el directorio bin de nuestro dominio WebLogic.
2. Localizar y editar alguna línea que inicia con la cadena PRE_CLASSPATH, en esta línea agregamos el nombre, incluyendo la ruta, de cada una de las librerías. Por ejemplo: PRE_CLASSPATH="${PRE_CLASSPATH}${CLASSPATHSEP}/u03/apps/custom/libs/com.betinox-core-2.0.2.jar:/u03/apps/custom/libs/lib_FML.zip"
3. Reiniciar el servidor WebLogic.

c) Mi preferido, todo lo hacemos desde la consola de administración que para eso es. Este método nos funciona tanto para archivos JAR como ZIP, para esta forma es necesario que el Node Manager este en funcionamiento y sea este quien arranque el servidor WebLogic.

1. Ingresar a la consola de administración WebLogic
2. Ir a la sección del servidor Manejado en el cual se desean cargar las librerías, es decir, en donde se ejecuta nuestra aplicación.
3. Ir a la pestaña Inicio del Servidor (Server Start) y ubicar el campo CLASSPATH, en este campo agregamos el nombre, incluyendo la ruta, de cada una de las librerías. Por ejemplo: /u03/apps/custom/libs/com.betinox-core-2.0.2.jar:/u03/apps/custom/libs/lib_FML.zip
4. Reiniciar el servidor WebLogic.

Cada una tiene sus ventajas y desventajas, podemos utilizar la que más se nos acomode considerando mantenimiento y rendimiento.

Hasta la próxima.

Configuración de dominio WebLogic (2a Parte) - Node Manager básico

Esta es la segunda parte del post Configuración de Dominio WebLogic, en el que de manera básica creamos y configuramos un dominio WebLogic.

WebLogic Server incluye un servicio extra denominado Node Manager que nos brinda los siguientes beneficios:

• Administración del ciclo de vida de los servidores WebLogic, incluyendo el servidor de administración. Nos permite iniciar, detener, pausar o reiniciar las instancias WebLogic.
• Monitoreo de los servidores WebLogic para determinar su estatus, teniendo la capacidad de reiniciarlos automáticamente.
• Nos permite administrar el ciclo de vida de los servidores desde la Consola de Administración WebLogic. Si los servidores WebLogic no tienen un Node Manager asociado no pueden ser manejados desde la Consola.
• Esta habilitado para recuperar los archivos log de los servidores, útil en escenarios en donde por razones de seguridad la Consola de Administración no esta disponible y/o no tenemos acceso al sistema de archivos.
• En arquitecturas de alta disponibilidad registra e inicia las direcciones de IP, flotantes, para los servidores manejados, etc.

En el post anterior (Configuración de Dominio WebLogic) durante la creación del dominio se realizo la asignación de una máquina a los servidores WebLogic, requisito para la administración con Node Manager. De manera lógica, una maquina establece un enlace entre uno o más servidores WebLogic y un Node Manager.

Desde la Consola de Administración también podemos realizar dicha asociación cuando el dominio ya fue creado. Realiza los siguientes pasos para asociar una máquina a un servidor WebLogic desde la Consola de Administración.

1. Crear una máquina con la dirección IP y puerto de un servicio Node Manager, el cual será el responsable para administrar el servidor WebLogic. En este ejemplo creo una máquina de tipo Unix y Plain (Plano, dado que no vamos a utilizar SSL). 
2. En la sección de configuración del Servidor WebLogic, seleccionar la máquina con la que se desea asociar.

El objetivo de esta entrada es ejemplificar como podemos comenzar a trabajar con Node Manager una vez que nuestros servidores WebLogic ya están asociados a una maquina.

Por default, la instalación WebLogic genera un directorio "home" en el que se encuentran todos los archivos de configuración para ejecutar un servicio Node Manager. Este directorio se encuentra en la siguiente ruta:

$NM_HOME= $MW_HOME/wlserver_10.3/common/nodemanager

Nota: Inicialmente este directorio cuenta con un sólo archivo (nodemanager.domains), el resto se puede auto-generar después de iniciar por primera vez el servicio.

1. Nos aseguramos que nuestro dominio esta registrado en el Node Manager. Abrimos el archivo nodemanager.domains y lo comprobamos, por ejemplo:

--- nodemanager.domains ---

#Domains and directories created by Configuration Wizard

#Fri Dec 21 14:56:30 CST 2012

jupiter_domain=/opt/oracle/mw/user_projects/domains/jupiter_domain

-------------------------------

2. Iniciamos el servicio Node Manager con la dirección IP y puerto que especificamos en la configuración de la maquina asociada a los servidores WebLogic.

Para iniciar el servicio debemos ir a la ruta $MW_HOME/wlserver_10.3/server/bin y ejecutar el script startNodeManager.sh, por ejemplo:

$./startNodeManager.sh 10.1.120.50 15556

Si el servicio inicia correctamente deberíamos ver algo como lo siguiente:

Detenemos el servicio con sólo teclear Ctrl + C.

Comprobamos que el programa generó los archivos de configuración del Node Manager. En nuestro NM_HOME estarán los siguientes archivos:
nm_data.properties
nodemanager.domains
nodemanager.log
nodemanager.properties

4. En este ejemplo voy a editar el archivo nodemanager.properties para modificar los siguientes parámetros:

Parámetro	Descripción	Valor por defecto	Nuevo valor
SecureListener	El servicio Node Manager requiere SSL.	true	false
CrashRecoveryEnabled	Mantiene el estado de ejecución (detenido, en ejecución) de los servidores WebLogic después de un reinicio del sistema operativo.	false	true
StartScriptEnabled	Utiliza el script startWebLogic.sh o startWebLogic.cmd para iniciar los servidores WebLogic.	false	true

Nota: El parámetro SecureListener obliga al Node Manager a utilizar SSL lo cual esta fuera de este ejemplo.

5. Nuevamente iniciamos el Node Manager, en esta ocasión ya no es necesario especificar la dirección ni el puerto. Si la edición fue correcta veremos algo como lo siguiente:

Hasta aquí el servicio de Node Manager ya esta listo para administrar nuestros servidores WebLogic.

6. Asumiendo que el servidor de administración no se encuentra en ejecución tenemos dos opciones para iniciarlo:

• Iniciarlo a través del Node Manger con lo que éste último tendrá el control para iniciarlo, detenerlo, etc.
• Iniciarlo con el script startWebLogic.sh con lo que el Node Manager no tiene acción sobre el servidor administración, pero si puede tener sobre el resto de servidores manejados.

En este ejemplo voy a iniciar el servidor de administración con el script startWebLogic.sh, como se indica en el post anterior. Iniciarlo a través del Node Manager implica una configuración extra además de cierto conocimiento en WLST, lo dejaremos para otro post. 

7. Una vez que el servidor de administración esta en ejecución, y la Consola de Administración esta disponible, podemos habilitar las opciones para que el Node Manager reinicie automáticamente algún servidor en caso de haber detectado un estado crítico.

Finalmente desde la misma consola ya podemos iniciar, parar, pausar y resumir nuestros servidores manejados.

Espero que esto les sirva, bienvenida cualquier duda o comentario.

Monitoreo de Recursos WebLogic con WebLogic Diagnostic Framework (WLDF)

El Servidor WebLogic incluye un módulo específico para el monitoreo y diagnóstico  tanto de sus propios recursos como los de las aplicaciones que sirve, éste modulo se denomina WebLogic Diagnostic Framework (WLDF). Por ejemplo, WLDF nos pérmite el monitoreo y diagnóstico de:

• La JVM sobre la cual esta corriendo el propio servidor WebLogic.
• Recursos JDBC, como Datasource, Multidata Source.
• Recursos JMS, como servidores JMS, fábricas de conexión, entre otros.
• Aplicaciones Web, EJB, etc.
• Y mucho más, en donde hace hechar a volar nuestra imaginación.

Para efectos de respuesta inmediata, WLDF proporciona varios mecanismos para la notificación de una alerta cuando se ha cumplido el criterio de una condición, y que determina un estatus específico de un recurso o del sistema entero. Por ejemplo: 

• La notificación cuando el uso de memoria ha alcanzado el 80% se puede realizar a través de un correo electrónico a la cuenta del administrador del sistema.
• La notificación cuando en el log del servidor se ha detectado el código de error BEA-320034 se puede realizara a través de un servidor SNMP.
• La notificación de threads atorados (StuckThreads) puede emitir un mensaje JMS, o una notificación JMX.
• Crear una imagen de diagnóstico cuando ocurre una excepción inesperada (UncheckedException).

Como siempre, WebLogic Server facilita la configuración y puesta en marcha del módulo WLDF a través de la Consola de Administración, utilizando una cuenta con privilegios de admnistrador.

A continuación voy a ejemplificar el uso de WLDF para la detección de StruckThreads y su notificación a través de correo electrónico. Este procedimiento puede servirles como guía para otros casos.

1. Ingresamos a la Consola de Administración WebLogic y a través del panel de estructura de dominio nos dirigímos a la sección Services > Mail Sessions. En ésta sección creamos una Sesión de Mail que utilizaremos para el envío de la notificación por correo electrónico.

Como destino del recurso seleccionamos todos aquellos servidores en donde queremos realizar el monitoreo.

Nota: La implementación de Mail Session no soporte conexiones a servidores que requieren SSL, en este caso necesitamos de un servidor SMTP que acepte conexiones sin SSL.

2. Ahora nos dirigímos a Diagnostic > Diagnostic Modules. En esta sección comenzamos a crear nuestro Módulo de Diagnóstico.

3. Una vez creado, entramos a la configuración del mismo y nos vamos a la sección Configuration > Watches and Notifications > Notifications. En este apartado creamos la notificación de tipo SMTP (E-Mail).

Por simplicidad dejo valores por defecto.

4. En el apartado Watches configuramos las propiedades de nuestro monitor para la detección y notificación de StuckThreads.

5. Finalmente, en la sección Targets seleccionamos los destinos (servidores) en los que deseamos mantener el monitoreo, similar a los destinos de nuestra Sesión de Mail. Salvamos y activamos los cambios.

En este punto, los servidores WebLogic estan habilitados para notificar por correo electrónico cuando se presente un error 'WL-000337' o 'BEA-000337', los cuales indican un problema en los hijos de ejecución del servidor (StuckThreads).

En la siguiente figura se resalta un ejemplo de la detección de un StuckThread, derivado del thread '8' con 658 segundos de ejecución, superior al máximo permitido antes de ser considerado como Stuck.

Este es un pequeño ejemplo de lo que podemos hacer con WLDF, en donde tenemos otro método de monitoreo más especifico y profundo, como lo es la Instrumentación y su capacidad para el rastreo de peticiones a recursos del sistema o aplicaciones personalizadas.

Espero que les sea utilidad para configurar diferentes alertas con las cuales puedan mejorar la prevención y/o detección de fallas en sus dominios WebLogic.

Configuración del administrador de trabajo por defecto (default Work Manager) en WebLogic

Un caso muy usual durante la operación del servidor WebLogic consiste en mejorar el rendimiento y eficacia del servidor; Generalmente esto se necesita cuando se requiere un mejor tiempo de respuesta de las aplicaciones o para soportar una elevada carga de trabajo (cientos de peticiones por minuto).

Para solventar dicho requisito, es necesario realizar una afinación, no sólo del servidor WebLogic, sino también del Sistema Operativo, Red y, en algunos casos, de la Base de Datos utilizada por nuestra aplicación.

En el servidor WebLogic se pueden realizar varias tareas para mejorar el rendimiento del mismo, por ejemplo:

• Ajustar parámetros de la Maquina Virtual de Java (JVM)
• Ajustar nivel y tipo de registro (Logging)
• Ajustar parámetros de orígenes de datos (DataSources), si existen
• Ajustar la administración de trabajo, hilos y timeouts (WorkManager)
• Ajustar sistema de Entrada/Salida (I/O System)
• Entre otras.

En esta ocasión sólo hablaré de la administración de carga de trabajo y la configuración que podemos realizar para aprovecharlo. Con el ajuste del WorkManager se pretende principalmente lo siguiente:

• Especificar el tiempo respuesta máximo que el servidor debería de tolerar.
• Especificar la carga máxima de trabajo, es decir, cuantas peticiones  y/o clientes puede soportar por un tiempo.
• Especificar el tiempo de espera máximo para la ejecución de una tarea, con el fin de liberar recursos y continuar con otras tareas.

La configuración del WorkManager la podemos aplicar de dos maneras:

• Dentro de los archivos de despliegue de nuestra aplicación, resultando  efectivo sólo para esta aplicación. Este se denomina administrador de trabajo de aplicación (Application WorkManager)
• Desde la consola de administración WebLogic, efectivo para una o más aplicaciones y/o recursos en el servidor. Este se denomina administrador de trabajo global (Global WorkManager)      

De manera nativa, cada dominio WebLogic  cuenta con un WorkManager por defecto, que se asigna a cada servidor manejado y al servidor de administración para  procesar el trabajo que deben ejecutar. También, por defecto este WorkManager no está visible en la consola de administración WebLogic.

Para mejorar el rendimiento del servidor WebLogic podemos sobre-escribir el WorkManager por defecto, para  ello hacemos lo siguiente:

1. Entrar a la consola de Administración WebLogic con un usuario con privilegios de administrador.
2. Crear un WorkManager con el nombre default, y asígnarlo a todos los servidores existentes en el dominio. Ver imagen 01.
3. Entrar a la configuración del nuevo WorkManager y especificar los atributos del mismo, crear cada uno de ellos con los valores con los que pretendemos mejorar el rendimiento. Ver imagen 02.

          Por ejemplo:

Atributo	Tipo	Objetivo	Valor afinado
Request Class	Response Time Request Class	Mejorar el tiempo de respuesta.	500 milisegundos
Request Class	Fair Share Request Class	Mejorar el tiempo de respuesta.	75
Minimum Threads Constraint		Buena práctica	10
Maximum Threads Constraint		Soportar mayor carga de trabajo	200
Capacity Constraint		Soportar mayor carga de trabajo	100
Ignore Stuck Threads		Incrementar tolerancia a fallas	Habilitado

            Estos atributos deben tener el mismo destino que el WorManager.

Una vez guardado y activado los cambios, el WorkManager está listo. Todas las aplicaciones y recursos son atendidas por el mismo WorkManager por defecto, no obstante, ahora tiene nuevos valores para mejorar su rendimiento. 

Adicionalmente, podemos crear WorkManager personalizados y asignarlos a servidores específicos, en donde se busque un diferente rendimiento, claro, siempre será un mejor rendimiento.

En un ambiente productivo, se recomienda crear un WorkManager personalizado para una o más aplicaciones, o simplemente para una aplicación de misión crítica. Para que nuestras aplicaciones hagan uso de dicho WorkManager, es necesario incluir la referencia a éste en el descriptor de despliegue weblogic-application.xml, por ejemplo:

<?xml version = '1.0' encoding = 'windows-1252'?>

<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                      xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd"

                      xmlns="http://www.bea.com/ns/weblogic/weblogic-application">

  …

  <work-manager>

    <name>MiWorkManager</name>

  </work-manager>

  …

</weblogic-application>

En este mismo descriptor se puede definir un WorkManager y todos sus atributos, que aplicarían sólo a esta aplicación.

Imagen 01.

Imagen 02.

Despliegue de un cliente Axis en WebLogic

Recientemente un cliente necesitaba consumir un servicio Web en Axis que adicionalmente está protegido con una política WSS4J (token x509), dada la no interoperabilidad con Oracle Web Service Manager para esta política se desarrolló una aplicación cliente que pudiera consumir el servicio. Ahora el desafío era hacer el deploy de dicha aplicación en Oracle WebLogic Server, esta aplicación estaría expuesta como servicio Web para que pudiese ser utilizada desde un proceso BPEL.

En este caso utilizamos JDeveloper para configurar nuestra applicación, es de gran ayuda para crear los descriptores de despliegue que se requieren. Los puntos clave para lograr el deploy son:

1. Dar prioridad a las librerias requeridas en el descriptor de despliegue weblogic.xml. Si no existe lo creamos dentro del directorio WEB-INF de nuestra web application.

<?xml version = '1.0' encoding = 'UTF-8'?>

<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                  xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"

                  xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">

  <container-descriptor>

    <prefer-web-inf-classes>true</prefer-web-inf-classes>

  </container-descriptor>

</weblogic-web-app>

2. Especifiar los paquetes que debe utilizar, en este caso los de Axis y no los de WebLogic, así como los parsers de XML requeridos por el mismo axis. Creamos o modificamos el descriptor weblogic-application.xml, por ejemplo:

<?xml version = '1.0' encoding = 'UTF-8'?>

<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                      xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd"

                      xmlns="http://www.bea.com/ns/weblogic/weblogic-application">

  <xml>

    <parser-factory>

      <saxparser-factory>org.apache.xerces.jaxp.SAXParserFactoryImpl</saxparser-factory>

      <document-builder-factory>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</document-builder-factory>

      <transformer-factory>org.apache.xalan.processor.TransformerFactoryImpl</transformer-factory>

    </parser-factory>

  </xml>

  <prefer-application-packages>

    <package-name>org.w3c.dom.*</package-name>

    <package-name>org.xml.sax.*</package-name>

    <package-name>com.ctc.wstx.*</package-name>

    <package-name>com.sun.activation.*</package-name>

    <package-name>com.sun.org.apache.*</package-name>

    <package-name>oracle.core.lmx.*</package-name>

    <package-name>oracle.core.lvf.*</package-name>

    <package-name>oracle.jdbc.*</package-name>

    <package-name>oracle.jdbc.connector.*</package-name>

    <package-name>oracle.jdbc.driver.*</package-name>

    <package-name>oracle.jdbc.internal.*</package-name>

    <package-name>oracle.jdbc.oci.*</package-name>

    <package-name>oracle.jdbc.oracore.*</package-name>

    <package-name>oracle.jdbc.pool.*</package-name>

    <package-name>oracle.jdbc.util.*</package-name>

    <package-name>oracle.jdbc.xa.*</package-name>

    <package-name>oracle.jpub.runtime.*</package-name>

    <package-name>oracle.net.ano.*</package-name>

    <package-name>oracle.net.jndi.*</package-name>

    <package-name>oracle.net.ns.*</package-name>

    <package-name>oracle.net.nt.*</package-name>

    <package-name>oracle.net.resolver.*</package-name>

    <package-name>oracle.security.o3logon.*</package-name>

    <package-name>oracle.sql.*</package-name>

    <package-name>oracle.sql.converter.*</package-name>

    <package-name>org.apache.*</package-name>

    <package-name>org.springframework.*</package-name>

  </prefer-application-packages>

</weblogic-application>

3. Hacer el deploy de la aplicación (EAR) no del proyecto, para que se lleve el weblogic-application.xml. Y no olvidemos especificar que el empaquetado del proyecto (WAR) incluya las librerías requeridas.

4. Opcionalmente, si el servicio Web que va a consumir nuestro cliente esta protegido con WSS4J, registramos el proveedor de seguridad en el JDK que utiliza nuestro servidor WebLogic (esto requiere reiniciar el servidor).

     - Colocar la libreria bcprov-jdk15-132.jar en $JDK_HOME/jre/lib/ext

      - Modificar el archivo java.security localizado en $JDK_HOME/jre/lib/security. Agregar la clase org.bouncycastle.jce.provider.BouncyCastleProvider como provider. Por ejemplo:

security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider

     Con esta configuración evitamos el siguiente error:

org.apache.axis2.AxisFault: WSHandler: Encryption: error during message processingorg.apache.ws.security.WSSecurityException: An unsupported signature or encryption al

gorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)

Aqui les dejos algunos sitios que me ayudaron a realizar el deploy:
http://techasilo.blogspot.mx/2007/04/call-to-web-service-has-become-nerve-of.html
http://blog.guident.com/2011/12/deploying-axis2-applications-on-oracle-weblogic-server/
http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200609.mbox/%3c4e3ba4880609010756i59e0a5b6s12d875f0b2263c1f@mail.gmail.com%3e

Cambiar la versión de Java (JDK) en WebLogic

Algunas veces es necesario actualizar o cambiar la versión de Java (JVM - JDK) que actualmente tenemos instalado. Podemos hacer este cambio ya sea para toda la instalación del software que tiene como raíz nuestro Middleware Home o simplemente para un dominio WebLogic.

Voy a presentar el procedimiento que se realizo para cambiar la versión del JDK 1.6 a la 1.7 de una instalación WebLogic y que además cuenta con Oracle SOA Suite, Oracle Service Bus.

En este escenario tenemos dos servidores de aplicación, soahost1 y soahost2, aprovisionados con:

WebLogic Server 11g

Oracle SOA Suite con Oracle Service Bus 11g

$MW_HOME representa nuestro Middleware Home.

1. Parar todos los servicios, tanto en los servidores de aplicación como en el servidor Web.

a.       Node Manager

b.      Servidores Manejados

c.       Servidor de Administración

2. Actualizar el archivo commEnv.sh con la ruta del JDK 1.7

$MW_HOME/wlserver_10.3/common/bin/commEnv.sh

3. Actualizar el archivo setDomainEnv.sh de nuestros dominio(s) WebLogic.

$MW_HOME /user_projects/domains/soa_domain/bin/setDomainEnv.sh

4. Opcionalmente y para ser consistente actualizamos el archivo nodemanager.properties de nuestros Node Managers.

$MW_HOME /wlserver_10.3/common/nodemanager/nodemanager.properties

5. Iniciar los servicios

6. Comprobar que se ha tomado la nueva versión de Java, revisamos los logs