Sun Java System Application Server Edición Enterprise 8.2 es un servidor compatible con la plataforma J2EE 1.4 para el desarrollo y la implementación de aplicaciones J2EE y servicios web basados en tecnologías Java en entornos de producción a gran escala.
En este capítulo se incluyen los temas siguientes:
Application Server Edición Enterprise 8.2 incluye las siguientes mejoras:
Administración mejorada: Application Server admite la administración segura y remota de implementaciones de empresa complejas en varios equipos mediante una consola basada en explorador o una interfaz de línea de comandos que permita la inclusión de secuencias de comandos. También proporciona una API enriquecida basada en JMX que permite el acceso remoto, seguro y programado a funciones administrativas y de supervisión.
Agente de mensajes: Application Server incluye un agente integrado de mensajes de clase empresarial que proporciona un servicio de mensajería escalable y fiable, de alta disponibilidad y rendimiento.
Message Queue 3.7: Application Server ahora implementa MQ 3.7.
Mayor compatibilidad con plataformas: ahora se admiten sistemas operativos, bases de datos, hardware y configuraciones regionales adicionales.
Sun Java Enterprise System: como componente clave de Sun Java Enterprise System, Application Server ofrece una integración sólida con servicios de identidades de red y de portal.
Herramientas de migración y actualización: estas herramientas le permiten comprobar si las aplicaciones J2EE se ajustan a los estándares de conformidad y portabilidad; le ayudan con la migración desde otras instancias de J2EE Application Server (como JBoss, WebLogic, WebSphere, etc.), así como a actualizar versiones previas de Sun ONE Application Server o iPlanet Application Server.
Compatibilidad con Java 2 Standard Edition 5.0: Application Server es compatible con Java 2 Standard Edition 5.0, que incluye funciones de supervisión y administración mejoradas, así como otros avances en cuanto a rendimiento y escalabilidad.
Compatibilidad con los complementos Java Web Services Developer Pack 1.6 (JWDSP): ahora se admite el uso de todos los complementos JWSDP. JWSDP 1.6 se puede descargar gratis desde http://java.sun.com/webservices/downloads/1.6/index.html.
Compatibilidad con base de datos Java DB: Application Server incluye la base de datos Java DB, basada en Apache Derby. Se mantiene la compatibilidad con versiones anteriores de la base de datos Pointbase; sin embargo, cualquier nueva base de datos creada en el servidor utilizará Java DB de forma predeterminada. Después de la actualización desde Application Server 8.x, los dominios existentes continuarán utilizando PointBase; sin embargo, los nuevos dominios creados tras la actualización utilizarán Java DB.
Controladores JDBC: con Application Server se incluyen controladores Sun JDBC.
Seguridad en los servicios web: los mecanismos de seguridad de mensajes de contenedores implementan autenticación a nivel de los mensajes (por ejemplo, firma digital XML y cifrado) de invocaciones de servicios web SOAP utilizando los perfiles de nombre de usuario o contraseña X.509 del estándar de seguridad OASIS WS-Security.
WS-I Basic Profile 1.1: tal y como establece la especificación J2EE 1.4, esta versión incluye Web Services Interoperability (WS-I) Basic Profile 1.1 para hacer posible la interoperabilidad entre aplicaciones de servicios web.
Conectividad con servicios secundarios mediante adaptadores iWay: Sun Microsystems distribuye y admite ahora 22 adaptadores iWay para los sistemas de servicios secundarios fundamentales (SAP, Siebel, Oracle, CICS e IBM MQ Series) que permitirán obtener un mayor rendimiento de sus aplicaciones de TI existentes desde el entorno de Application Server. Estos adaptadores son compatibles con la especificación J2EE Connector Architecture 1.5 y los estándares de los servicios web (SOAP). Además, incluyen herramientas de desarrollador para reducir el tiempo de conexión con las aplicaciones secundarias.
Último sistema de administración HADB: las plataformas UNIXTM contienen el nuevo sistema de administración de bases de datos de alta disponibilidad (HADB versión 4.4.3), que incluye Database Server, el controlador ODBC 2.5, el controlador JDBC 3.0 de tipo 4, clusql (un programa interactivo para introducir y ejecutar instrucciones SQL) y un sistema de administración. En esta versión se elimina la dependencia de SSH/RSH, pero se requiere que la red esté configurada para la multidifusión UDP. Consulte Sun Java System Application Server Enterprise Edition 8.2 High Availability Administration Guide para obtener más información sobre requisitos y limitaciones HADB.
Compatibilidad con las zonas de Solaris 10: Application Server puede instalarse en una zona global o no global en los sistemas Solaris 10. Consulte la página dezonas de Solaris para obtener más información.
Omitida compatibilidad con tecnología de contenido dinámico: ya no se admiten tecnologías de contenido dinámico, como, por ejemplo, CGI-bin y SHTML.
En este apartado se describen los requisitos que se deben cumplir para poder instalar el producto Sun Java System Application Server Edición Enterprise 8.2.
En la siguiente tabla se indican los sistemas operativos que son compatibles con el producto Sun Java System Application Server Edición Enterprise 8.2. Además, se especifican los requisitos mínimos y máximos de memoria necesarios para instalar y ejecutar Application Server.
Tabla 2–1 Requisitos de plataforma de Sun Java System Application Server 8.2
Los requisitos del sistema indicados arriba para Application Server, así como los indicados para HADB en Requisitos de HADB y plataformas compatibles no son exactamente los mismos. Esto no es un error de documentación. Es ya habitual ejecutar Application Server y un servidor HADB en distintos equipos.
En UNIX, puede averiguar cuál es su versión del sistema operativo utilizando el comando uname . El espacio en disco se puede comprobar con el comando df.
Debe utilizar un sistema de archivos NTFS en lugar de FAT o FAT32 al ejecutar Application Server en cualquier plataforma de Microsoft Windows.
La virtualización del sistema es una tecnología que permite que varias instancias del sistema operativo (SO) se ejecuten de forma independiente en un hardware compartido. Desde el punto de vista de la funcionalidad, el software implementado en un SO alojado en un entorno virtualizado no reconoce normalmente que la plataforma adyacente se ha virtualizado. Sun realiza pruebas a sus productos de Sun Java System en determinadas combinaciones de SO y virtualización de sistemas para confirmar que los productos de Sun Java System siguen funcionando en entornos virtualizados con una configuración y un tamaño correctos del mismo modo que lo harían en sistemas que no se hayan virtualizado. Para obtener más información sobre asistencia Sun para productos Sun Java System en entornos virtualizados, consulte System Virtualization Support in Sun Java System Products .
Es aconsejable que los usuarios de Solaris 9, 10 (x86, SPARC) tengan instalados los “clústeres de revisiones recomendadas de Sun”, que se encuentran en el apartado Recommended and Security Patches en SunSolve.
Para ejecutar los componentes nativos de este producto (incluido el instalador), hay que instalar el siguiente paquete que no forma parte de la distribución estándar de RedHat Enterprise Linux 3.0: compat-libstdc++-7.3-2.96.118.i386.rpm
El paquete puede descargarse desde http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html.
Sun Java System Application Server está diseñado para admitir la conectividad con cualquier DBMS que tenga un controlador JDBC correspondiente. Para obtener la lista de los componentes que Sun ha probado y ha considerado aceptables para construir configuraciones de bases de datos compatibles con J2EE, consulte la siguiente tabla.
Tabla 2–2 Controladores JDBC compatibles con J2EE
Proveedor de JDBC |
Tipo de controlador JDBC |
Servidor de base de datos admitido |
---|---|---|
i-net Software |
Tipo 4 |
Oracle (R) 8.1.7, 9i, 9.2.0.3+, 10.1.x, 10.2. x Sybase ASE 12.5. Microsoft SQL Server 2000 4.0 Service Pack 1 |
IBM |
Tipo 2 |
IBM DB2 8.1 Service Pack 3+ |
Java DB |
Tipo 4 |
Apache Derby 10.1.3 |
PointBase |
Tipo 4 |
PointBase Network Server 5.2 |
DataDirect |
Tipo 4 |
Oracle (R) 8.1.7, 9i, 9.2.0.3+, 10.1.x, 10.2. x Sybase ASE 12.5.2 Microsoft SQL Server IBM DB2 8.1 Service Pack 3+ |
MySQL |
Tipo 4 |
5.x |
Controlador JDBC de Sun Java System para Oracle |
Tipo 4 |
Oracle (R) 9.2.0.3, 10G |
Controlador JDBC de Sun Java System para DB2 |
Tipo 4 |
IBM DB2 8.1 Service Pack 3+ |
Controlador JDBC de Sun Java System para Sysbase |
Tipo 4 |
Sybase ASE 12.5.2 |
Controlador de JDBC de Sun Java System para Microsoft SQL Server |
Tipo 4 |
Microsoft SQL Server 2000 4.0 Service Pack 1 |
Oracle |
Tipo 4, Tipo 2 |
Oracle (R) 9.2.0.3, 10G |
En esta sección, se proporcionan instrucciones de uso de la implementación de la base de datos Java DB incluida con Application Server 8.2.
Sun Java System Application Server 8.2 presenta dos nuevos comandos asadmin para iniciar y detener el servidor de red Java DB.
El comando start-database puede utilizarse para iniciar una instancia del servidor de red Java DB:
start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome path/derby] |
El valor predeterminado del host es 0.0.0.0, que permite a Java DB recibir las solicitudes en localhost, así como las interfaces de IP/nombre de host. El valor de la propiedad dbhome es la ubicación de las bases de datos Java DB. La ruta predeterminada es <appserver_install_dir>/derby.
El comando asadmin stop-database se utiliza para detener la instancia del servidor de red Java DB que se está ejecutando:
stop-database [--dbhost 0.0.0.0] [--dbport 1527] |
La configuración de Java DB incluida con Application Server 8.2 también presenta varias secuencias de comandos útiles que pueden ayudarle a usar Java DB. Están disponibles las siguientes secuencias de comandos para su uso en el directorio <appserver_install_dir> /derby/frameworks/NetworkServer/bin:
startNetworkServer.ksh/bat: secuencia de comandos que se utiliza para iniciar el servidor de red.
stopNetworkServer.ksh/bat: secuencia de comandos que se utiliza para detener el servidor de red.
ij.ksh/bat: herramienta de creación de secuencias de comandos interactiva de JDBC.
dblook.ksh/bat: secuencia de comandos que permite ver de forma parcial o completa un DDL para la base de datos.
sysinfo.ksh/bat: secuencia de comandos que muestra información de la versión en relación con el entorno de Java DB.
NetworkServerControl.ksh/bat: secuencia de comandos que proporciona un método para ejecutar comandos en la API de NetworkServerControl .
Defina la variable de entorno DERBY_INSTALL para que señale al directorio <appserver_install_dir>/derby.
Anule la definición de la variable de entorno CLASSPATH.
También puede definir opcionalmente las siguientes propiedades:
Para obtener más información sobre estas utilidades, consulte las herramientas y las guías de administración de Derby.
Este ejemplo muestra cómo capturar el DDL de una tabla en Pointbase y crear la misma tabla en Java DB mediante Netbeans 5.0. También puede utilizar la herramienta de comandos y el comando unload database:
./startcommander.sh Do you wish to create a new Database. (Yes (Y) or No (N))? [default: N]: Enter product to connect with: (Embedded (E) or Server (S))? [default: E]: e Enter driver to use? [default: [com.pointbase.jdbc.jdbcUniversalDriver]: Enter database URL? [default: [jdbc:pointbase:embedded:sample]: Enter Username? [default: PBPUBLIC]: Enter Password? [default: PBPUBLIC]: PointBase Commander 5.2 ECF build 294 size restricted version EMBEDDED Interactive SQL command language. SunOS/5.9 (C) Copyright 2004 DataMirror Mobile Solutions, Inc. All rights reserved. Licensed to: Sun_customer_demo_use For commercial version contact PointBase at: pointbase.com PHONE: 1-877-238-8798 (US & CANADA) 1-408-961-1100 (International) WEBSITE: www.pointbase.com SQL>unload database sampledb.sql; SQL> unload database sampledb.sql; SQL> 13 Row(s) Unloaded. (PBPUBLIC.CUSTOMER_TBL) SQL> 4 Row(s) Unloaded. (PBPUBLIC.DISCOUNT_CODE_TBL) SQL> 30 Row(s) Unloaded. (PBPUBLIC.MANUFACTURE_TBL) SQL> 11 Row(s) Unloaded. (PBPUBLIC.MICRO_MARKETS_TBL) SQL> 9 Row(s) Unloaded. (PBPUBLIC.OFFICE_TBL) SQL> 4 Row(s) Unloaded. (PBPUBLIC.OFFICE_TYPE_CODE_TBL) SQL> 15 Row(s) Unloaded. (PBPUBLIC.ORDER_TBL) SQL> 6 Row(s) Unloaded. (PBPUBLIC.PRODUCT_CODE_TBL) SQL> 30 Row(s) Unloaded. (PBPUBLIC.PRODUCT_TBL) SQL> 10 Row(s) Unloaded. (PBPUBLIC.SALES_REP_DATA_TBL) SQL> 10 Row(s) Unloaded. (PBPUBLIC.SALES_REP_TBL) SQL> 52 Row(s) Unloaded. (PBPUBLIC.SALES_TAX_CODE_TBL) SQL> 12 Table(s) Unloaded. SQL> quit;
Los resultados derivados de la ejecución de unload database se escriben en sampledb.sql, como se indica en el ejemplo anterior. El archivo sampledb.sql contiene todos los DDL necesarios para crear las tablas y los índices requeridos. También contiene el DML para insertar de nuevo los datos en la base de datos. El comando del programa de comandos RUN está diseñado para importar los datos en otra base de datos Pointbase mediante la secuencia de comandos generada. A continuación, se muestra un ejemplo de la apariencia que tienen las instrucciones INSERT y los datos asociados en el archivo generado:
INSERT INTO "ADVENTURE"."CATEGORY" ( "CATID", "LOCALE", "NAME", "DESCRIPTION", "IMAGEURI" ) VALUES( ?, ?, ?, ?, ? ); { 'ISLAND ','en_US','Island Adventures','Experience an island / paradise in a way fit for your needs.','Island_Adventures.gif' 'JUNGLE ','en_US','Jungle Adventures','Experience a jungle / paradise in a way fit for your needs.','Jungle_Adventures.gif' 'MOUNTAIN ','en_US','Mountain Adventures','Experience an / elevated paradise with a view.','Mountain_Adventures.gif' 'ORBITAL ','en_US','Orbital Adventures','Experience a vacuum / paradise with a beautiful view and where no one can hear you scream.', / 'Space_Adventures.gif' 'WESTERN ','en_US','Western Adventures','Enjoy the Wild West. / ','Western_Adventures.gif' 'SOUTH_POLE ','en_US','South Pole Adventures','Experience a / frozen paradise in a way fit for your needs.','SouthPole_Adventures.gif' };
Puede editar fácilmente el archivo generado a partir del comando unload database de tal forma que sólo esté compuesto por el DDL (por ejemplo, no sería tan complicado escribir un programa que procese las instrucciones insert). Como prueba, utilizamos el comando de anulación de la carga de la base de datos en la base de datos sample de Pointbase y, a continuación, editamos la secuencia de comandos generada, realizando los siguientes cambios:
Se ha eliminado Organization Heap del final de todas las instrucciones CREATE Table.
Se ha eliminado el comando COMMIT.
Se ha cambiado el valor booleano datatype por smallint .
Se han eliminado todas las instrucciones INSERT y sus datos asociados.
A continuación, se utiliza una secuencia de comandos Ant sencilla para ejecutar el DDL mediante el destino sql . Por último, se repite el mismo experimento para la base de datos sun-appserv-samples , que requiere que se efectúen los siguientes cambios adicionales en el archivo SQL generado:
Realice todos los cambios como se describe anteriormente para la base de datos de ejemplo.
Elimine los comandos create user.
Elimine los comandos SET PATH.
Cambie la precisión Decimal de 38 a un máximo, max, de 31.
Cambie la precisión float de 64 a un máximo, max, de 52.
Actualmente no se admite la palabra clave SPECIFIC para CREATE PROCEDURE.
Se han eliminado los comandos GRANT.
Para cambiar los procedimientos de Java de Pointbase para que funcionen con Java DB, es necesario realizar varios cambios en el código de Java, así como en las instrucciones CREATE PROCEDURE. Puede encontrar información sobre la creación de procedimientos de Java de Java DB en el manual de referencia de Derby. Se incluirá compatibilidad con el tipo de datos Boolean en la próxima versión de Java DB.
En esta sección, se indican los servidores web que son compatibles con Sun Java System Application Server Edición Enterprise 8.2.
Tabla 2–3 Servidores web compatibles
Web Server |
Versión |
Sistema operativo |
---|---|---|
Sun Java System Web Server |
6,0, 6.1, 7.0 |
Solaris SPARC 9, 10 Solaris x86 9, 10 Red Hat Enterprise Linux 3 y 4 |
Apache Web Server |
1.3+, 1.4, 2.0 |
Solaris SPARC 9, 10 Solaris x86 10 Red Hat Enterprise Linux 3 y 4 Windows Server 2003 Windows 2000 Advanced Server SP4+ Windows Server 2000 SP4+ Windows XP Pro SP1+ |
Microsoft IISTM |
5.0+ |
Windows Server 2003 Windows 2000 Advanced Server SP4+ Windows Server 2000 SP4+ Windows XP Pro SP1+ |
En esta sección, se indican los exploradores que son compatibles con Sun Java System Application Server Edición Enterprise 8.2.
Tabla 2–4 Exploradores web compatibles
Explorador |
Versión |
---|---|
Mozilla |
1.4, 1.5, 1.6, 1.7.x |
Netscape Navigator |
4.79, 6.2, 7.0, 8.x |
Internet Explorer |
5.5 Service Pack 2, 6.0 |
Firefox |
1.4, 1.5 |
Además de los requisitos que aparecen en Requisitos de hardware y software, compruebe que su sistema cumpla los requisitos que se indican a continuación para ejecutar HADB.
Los requisitos del sistema que aparecen en Requisitos de plataforma para Application Server y los indicados aquí para HADB no son exactamente los mismos. Esto no es un error de documentación. Es ya habitual ejecutar Application Server y un servidor HADB en distintos equipos.
Los componentes de Java del sistema se han creado con JDK 1.4.2_02 y se han probado con JDK 1.5_09.
Solaris (SPARC) – Solaris 8 MU7, Solaris 9 MU7 y Solaris 10 RR.
Solaris (x86) – Solaris 9 MU7 y Solaris 10 RR.
RedHat Enterprise Linux - 2.1 U5 (sólo se admite el sistema de archivos ext2, no ext3), 3.0 U4 (se admiten ext2 y ext3. Las actualizaciones anteriores a U4 no se recomiendan debido al excesivo intercambio). Tenga en cuenta que HADB se ha probado en estas versiones de sistemas operativos sólo en el modo de 32 bits. Tenga en cuenta también que HADB no es compatible con RedHat Enterprise Linux 3.0 cuando se ejecuta en modo de 64 bits debido a un error en el sistema operativo (consulte el error 6249685 en el apartado Alta disponibilidad para obtener más detalles acerca de las repercusiones en HADB).
Microsoft Windows – Microsoft Windows 2000 Advanced Server Service Pack 4 y Microsoft Windows 2003 Enterprise Edition. Tenga en cuenta que HADB no es compatible con ninguna de las próximas versiones de sistemas operativos de Microsoft Windows en el modo de 64 bits.
Memoria mínima: 512 MB por nodo.
Cantidad mínima de espacio libre en disco: 70 MB para binarios HADB por host. Además, se necesita espacio de disco para los dispositivos de datos; 512 MB para una instalación de prueba por cada nodo.
Memoria recomendada: 1 GB por nodo.
Espacio libre en disco recomendado: 70 MB para binarios HADB por host. Además, se necesita espacio de disco para los dispositivos de datos; 1200 MB para una instalación de prueba por cada nodo:
Asegúrese de que el almacenamiento en caché está desactivado en los dispositivos de almacenamiento de archivos de registro y datos HADB. La escritura en caché esta activada de forma predeterminada en algunas plataformas Solaris como, por ejemplo, Solaris x86.
Memoria mínima: 128 MB.
Cantidad mínima de espacio libre en disco: 70 MB para binarios HADB por nodo.
Memoria mínima: 120 MB.
Cantidad mínima de espacio libre en disco: 20 MB
No se admite la actualización "in situ" de las versiones anteriores de Application Server. Consulte Application Server Edición Enterprise Upgrade and Migration Guide para obtener instrucciones completas sobre la actualización de una versión anterior de Application Server a la versión actual.
Los siguientes requisitos adicionales se deben cumplir para poder instalar el software de Sun Java System Application Server.
Espacio libre: el directorio temporal debe tener un mínimo de 35 MB de espacio libre para la instalación de Sun Java System Application Server y 250 MB de espacio libre para la instalación de SDK.
Uso del programa de desinstalación: si necesita eliminar Application Server del sistema, es importante que utilice el programa de desinstalación incluido con el software. Si intenta utilizar cualquier otro método, surgirán problemas cuando intente reiniciar la misma versión o cuando desee instalar una versión nueva.
Puertos libres: debe disponer de siete puertos no utilizados.
El programa de instalación detecta automáticamente los puertos que están en uso y sugiere puertos libres para los ajustes predeterminados. De forma predeterminada, los puertos iniciales son 8080 para HTTP, 8181 para HTTPS y 4849 para Administration Server.
El programa de instalación detectará si los puertos están en uso y, en su caso, asignará otros dos: Sun Java System Message Queue (de forma predeterminada, 7676) e IIOP (de forma predeterminada, 3700 para IIOP, y 1060 y 1061 para IIOP/SSL). Si estos números de puertos predeterminados están en uso, el programa de instalación asignará un número de puerto aleatorio del intervalo de puertos dinámicos (es posible que no se asigne el puerto siguiente que esté disponible).
Inicio de servidores previamente instalados (UNIX): a menos que desee sustituir el servidor instalado con anterioridad, deberá iniciarlo antes de comenzar el proceso de instalación de Sun Java System Application Server 8.2. Esto permite que el programa de instalación detecte los puertos que están en uso y no los asigne para otros usos.
Sustitución de servidores previamente instalados (UNIX): si dispone de una versión antigua de Sun Java System Application Server instalada y desea sustituirla por la versión actual de Application Server, deberá detenerla antes de instalar el nuevo servidor. Use el asistente de actualización del programa de instalación para actualizar el servidor.
Cierre del servidor de seguridad (Microsoft Windows): debe detener cualquier tipo de software de servidor de seguridad antes de instalar Sun Java System Application Server porque algunos servidores de seguridad desactivan todos los puertos de forma predeterminada. El programa de instalación debe determinar con precisión qué puertos están disponibles.
Para obtener más información sobre la compatibilidad, consulteSun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide .
En este apartado se indican los problemas detectados por los clientes que se han resuelto en el producto Sun Java System Application Server Edición Enterprise 8.2.
Número de error |
Descripción |
---|---|
6368745 |
AS: no se puede actualizar de AS7 (Java ES 2) a AS8.2 (Java ES 5). |
6432308 |
AS, JES5b7a, actualización as de JES2 a JES5 falla. |
6378409 |
AS 8.2:compatibilidad con versiones anteriores interrumpida a causa de las bibliotecas jsf incluidas en 8.2. |
6371534 |
AS82EE:configure-ha-cluster bloquea Windows si la ruta de la instalación contiene espacios. |
6242761 |
Init no puede iniciar el agente del nodo como aparece documentado sin generar errores. |
6267772 |
Las instrucciones sobre la configuración de Borland OptimizeIt no son correctas. |
6273226 |
Se ha añadido el texto que indica que se debe agregar la opción jvm -Xrs que ejecuta un servidor/NA en ejecución como un servidor de ventanas. |
6361145 |
No se puede actualizar el complemento LB cuando se actualiza in situ de 8.1EE a 8.2EE. |
6362881 |
El programa de instalación no ofrece la opción de actualización cuando actualiza de 8.1ur2 a 8.2ee. |
6325988 |
Problema de interoperabilidad en la primera solicitud RMI-IIOP entrante con FVD/codeBase. |
6363689 |
JES5 ASEE8.2 versión 03: no se puede detener la instancia. |
6364900 |
Valor de sesión perdido durante la conmutación por error cuando una aplicación web incluye una segunda aplicación web. |
6370993 |
La conmutación por error de sesión falla cuando la raíz de contexto de aplicación se modifica a â/â en el clúster. |
6373729 |
El código de Appserver 8.1 no puede establecer comunicación con WebLogic 9.0 a causa de un conflicto ORB. |
6377594 |
Problemas de búsqueda con Weblogic initialcontext factory. |
6381538 |
Fallo de cliente independiente con NPE. |
6406055 |
WARNING: âIOP00110205: (BAD_PARAM) la referencia de objecto procedía de ORBâ org.omg externo.CORBA. |
6388329 |
Error de compilación de JSP en Application Server tras actualizar Access Manager. |
6419659 |
El complemento LB no redirecciona correctamente las solicitudes cuando la garantía de transporte es CONFIDENTIAL (CONFIDENCIAL). |
6390584 |
Error de memoria insuficiente: espacio PermGen |
6401424 |
SEGV de service_plain_range en libns-httpd40.so si se solicita un archivo PDF. |
6401704 |
Compatibilidad necesaria con WebDAV para AppServer 8.#. |
6416478 |
fallo de jsp testsuite: javax.servlet.jsp.el.ELException |
6438908 |
Ubicación de encabezado dañada si relativeRedirectAllowed=true. |
6456553 |
java.lang.IllegalArgumentException si hay cookies adjuntas a la respuesta. |
6295010 |
Las conexiones del conjunto fijo no están activas durante el tiempo de espera de inactividad que entra en conflicto con los servidores de seguridad. |
6350435 |
Application Server deja de administrar el fallo de una base de datos durante una operación XA en dos bases de datos. |
6377830 |
La configuración de setAutoCommit en "false" (falso) se propaga cuando el siguiente usuario utiliza la misma conexión. |
6399830 |
IT 319 : la función de alias de contraseña no funciona en domain.xml. |
6360040 |
SJAS 8.x : el usuario de enlace de dominio de LDAP de AppServer tiende a acceder a todos los grupos y miembros. |
6370095 |
No se puede establecer acceptor-thread en un valor superior a 10. |
6399365 |
InvokerServlet no está funcionando sólo en Enterprise Edition. |
6303835 |
Registro excesivo: mensajes de seguridad erróneos en el registro del servidor. |
6349541 |
8.1 EE UR2: no se pueden establecer los módulos de escucha de SSL enlazando a una dirección IP específica... |
6380040 |
Es necesaria una limpieza automática de archivos de registro. |
6387278 |
La autenticación del cliente se ha interrumpido o no es a prueba de fallos (Inicio de sesión mediante programación). |
6407896 |
HttpServletRequestWrapper que sobrescribe getUserPrincipal() da lugar a ClassCastException. |
6321194 |
La directiva de operación por turnos no está funcionando. |
6362269 |
Verifier no se ejecuta correctamente en Windows cuando la ruta de la instalación contiene un espacio. |
6365888 |
Las conexiones del conjunto de conexiones del conector predeterminado no aparecen enumeradas en las transacciones. |
6369554 |
El conjunto de conexiones necesita validar una conexión antes de ofrecérsela a una aplicación. |
6370574 |
Tras actualizar AS con la opción Configurar más tarde desaparece el directorio /var/opt/SUNWappserver. |
6371723 |
Al complemento lb le falta memoria para la versión completa del servidor web (más para Apache mod_loadbalancer). |
6395390 |
No se produce una operación por turnos en solicitudes http que experimentan conmutación por error. |
6402713 |
Falla el equilibrador de carga al conectarse con solicitudes HTTPS. |
6409992 |
Fallo en la actualización con certificado de 8.1pe a 8.2EE. |
6413224 |
La herramienta de actualización omitió la opción de actualización del certificado. |
6422893 |
El enrutamiento HTTPS no funciona. |
6424051 |
Es necesario utilizar las credenciales de administración existentes y MP en la actualización de 8.xPE a 9.1 EE. |
6424053 |
La actualización de 8.XEE->9.1EE falla con una excepción de start-domain. |
6430394 |
Los mensajes se pierden cuando hay un corte de n/w. |
6444052 |
Integración genérica RA para la versión JMS 1.5 en AS 8.2 EE. |
6444308 |
AS 8.1 UR2 EE-> 8.2 EE SS: No se pudo iniciar el dominio1 de versión 8.2; inicio de dominio de versión 8.1UR2 erróneo. |
6444368 |
La actualización se bloquea de 8.0PE UR1 a 9.1 ee en la GUI en paralelo de win2003. |
6446558 |
La recuperación de transacciones manual no funciona para los recursos del conjunto de conexiones del conector. |
6447895 |
La recuperación de transacciones no funciona para los recursos que utilizan RA incrustado. |
6454007 |
Cambie la entrada necesaria para la herramienta de actualización. |
6455396 |
El agente del nodo y las instancias dejan de iniciarse tras una actualización de 8.1EE->9.1EE SBS. |
6374533 |
Por motivos de rendimiento y estabilidad, Application Server debe incluir XWSS 1.1 y no XWSS 1.0. |
6358422 |
Appserver 7.1/8.1 EE: el complemento del proxy LB del servidor web debe ser compatible con las conexiones de mantenimiento. |
6382063 |
Pérdida de memoria en com.sun.enterprise.iiop.IORToSocketInfoImpl |
Este apartado describe información adicional importante acerca de la implementación de HADB incluida en Application Server 8.2.
El nuevo comando de administración hadbm setadminpassword se ha implementado para que sea posible cambiar la contraseña utilizada para la administración de la base de datos. El comando adopta opciones que indican qué agente de administración se debe usar y cuál es la contraseña nueva y la antigua. Para obtener más información, consulte la página de comando man hadbm setadminpassword.
El comando de administración existente hadbm listpackages se ha modificado. Anteriormente el comando no adoptaba operandos y enumeraba todos los paquetes del dominio de administración pertinente. Las modificaciones introducen un operando de nombre de paquete opcional, que muestra una lista que contiene sólo los paquetes con dicho nombre. Si no se especifica el operando, se mostrarán todos los paquetes. Para obtener más información, consulte la página de comando man hadbm listpackages.
El comando de administración existente hadbm createdomain se ha modificado. El operando hostlist se ha ampliado para que especifique también el número de puerto del agente de administración. De este modo, el dominio se especifica completamente usando sólo el operando hostlist. El comportamiento anterior todavía se admite para conseguir compatibilidad con versiones anteriores. Para obtener más información, consulte la página de comando man hadbm createdomain.
Algunos mensajes de error del sistema de administración se han modificado. Las modificaciones están destinadas a mejorar la comprensión, la coherencia y la precisión de los mensajes de error. Las modificaciones en sí no se indican en estas notas de la versión.
Los comportamientos de instalación y desinstalación se han modificado levemente. La instalación y la desinstalación de HADB deben conservar siempre los archivos softlink /opt/SUNWhadb/4, pero éste no siempre ha sido el caso.
La posibilidad de introducir contraseñas en la línea de comandos como opciones de comando ya no se admite. Esto es relevante para todos los comandos hadbm que usen contraseñas como opciones de la línea de comandos. En los comandos hadbm, antes era posible introducir una contraseña en forma de:
Un archivo de contraseña
Una opción de línea de comandos
Una entrada interactiva
El método 2, la opción de la línea de comandos, no se considera seguro y, en consecuencia, ha quedado obsoleto. Se muestra un mensaje de advertencia en el caso de que se introduzca una contraseña de este modo. En su lugar, use el método 1, un archivo de contraseña, o bien el método 3, la salida interactiva. El uso de una contraseña en la línea de comandos quedará obsoleto en la siguiente versión. Tenga en cuenta que esto es aplicable a todos los comandos hadbm que admiten una contraseña en la línea de comandos.
HADB se ha actualizado para que pueda usar JGroups Versión 2.2, y su código fuente se distribuye junto con HADB. Para que sea posible realizar una actualización en línea desde una versión anterior de HADB, tanto JGroups 2.1 como 2.2 se proporcionan con HADB. Para JGroups 2.1, se proporciona sólo la codificación de bytes.
Hay varias consideraciones importantes que hay que tener en cuenta a la hora de configurar HADB para que utilice uno de los siguientes sistemas de archivos:
ext2 y ext3: HADB es compatible con los sistemas de archivos ext2 y ext3 para Red Hat Application Server 3.0. En la versión Red Hat Application Server 2.1, HADB admite sólo el sistema de archivos ext2.
Veritas: si se usa el sistema de archivos Veritas en una plataforma Solaris, se incluirá el siguiente mensaje en el archivo de historial “WRN: Direct disk I/O mapping failed (WRN: error en la asignación de E/S directa de disco). Este mensaje indica que HADB no puede activar la función de E/S directa de los datos y los dispositivos de registro. La entrada o salida directa es una mejora en el rendimiento que reduce el coste de la CPU al escribir páginas de disco. Esto también provoca que haya una menor carga para administrar las páginas de datos no útiles en el sistema operativo.
Para usar la función de E/S directa con el sistema de archivos Veritas, siga uno de estos procedimientos:
Cree los datos y los dispositivos de registro en un sistema de archivos que esté montado con la opción mincache=direct. Esta opción se aplica a todos los archivos creados en el sistema de archivos. Consulte el comando mount_vxfs(1M) para obtener más detalles.
Use la utilidad Veritas Quick I/O para realizar entradas y salidas sin formato en los archivos del sistema de archivos. Consulte VERITAS File System 4.0 Administrator's Guide for Solaris para obtener más información.
Tenga en cuenta que estas configuraciones no han sido probadas con Application Server 8.2.
Consulte Application Server Edición Enterprise High Availability Administration Guide para obtener información sobre la instalación y la configuración de HADB con el software Application Server.
Los usuarios deben conservar los archivos del historial de HADB, los archivos de configuración del agente de administración, los archivos de registro y el repositorio y todos los dispositivos de datos externos a la ruta de instalación. De lo contrario, esto se debe hacer antes de la actualización. Para mover el repositorio de administración y los archivos de configuración:
Detenga todos los agentes de administración antiguos y deje los nodos de HADB ejecutándose.
En cada host, mueva el directorio del repositorio a la nueva ubicación.
En cada host, copie el directorio dbconfig en la nueva ubicación.
En cada host, actualice el archivo mgt.cfg y defina la ruta correcta para dbconfig y el directorio del repositorio.
Inicie los agentes de administración usando el archivo actualizado mgt.cfg.
Para actualizar de la versión 4.4.x de HADB a la versión 4.4.3, lleve a cabo el siguiente procedimiento:
Realice las tareas previas a la actualización mencionadas anteriormente si es necesario.
Instale la versión 4.4.3 de HADB en todos los hosts de HADB (en una ruta distinta de la de la versión 4.4.x, por ejemplo, en /opt/SUNWhadb/4.4.3).
Instale la versión 4.4.3 de HADB en los hosts del cliente hadbm, en caso de que sean diferentes de los de los hosts de HADB.
Detenga todos los agentes de administración que se estén ejecutando en todos los hosts de HADB.
Inicie los procesos del agente de administración usando el software de la nueva versión, pero con los archivos de configuración antiguos. En los pasos que quedan, utilice el comando hadbm que se incluye en el directorio bin de la nueva versión.
Registre el paquete en el dominio de administración (el nombre del paquete predeterminado pasa a ser V4.4, por lo que será necesario utilizar otro nombre de paquete para evitar conflictos con los paquetes existentes que tengan el mismo nombre):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.3 V4.4.3 |
Ejecute el comando hadbm listpackages y compruebe que el nuevo paquete esté registrado en el dominio.
Reinicie la base de datos con la nueva versión 4.4.3 de hadbm. Si es necesario mover los dispositivos y los archivos del historial, ejecute la actualización en línea junto con la definición de nuevas rutas para los dispositivos y los archivos del historial en una única operación:
hadbm set packagename=V4.4.3,devicepath=new_devpath, historypath=new_histpath |
De lo contrario, si los dispositivos y los archivos del historial están ya fuera del directorio de instalación, ejecute el siguiente comando, que sólo realiza un reinicio por turnos de los nodos:
hadbm set packagename=V4.4.3 database name |
Compruebe que la base de datos esté ejecutándose (para ello, use el comando hadbm status) y que funcione normalmente, atendiendo las transacciones de los clientes.
Si todo está funcionando, la instalación antigua podrá eliminarse posteriormente. Antes de anular el registro del paquete antiguo, elimine del depósito ma todas las referencias al mismo. De lo contrario, hadbm unregisterpackage fallará y mostrará un error que indica que el paquete está en uso ("package in use").Una operación de reconfiguración ficticia, por ejemplo, hadbm set connectiontrace=same as previous value, eliminará todas las referencias al paquete antiguo. Ahora, proceda a anular el registro del paquete antiguo:
hadbm unregisterpackage [--hosts=host-list] old pacakge name |
Elimine la instalación antigua del sistema de archivos.
En Solaris, para probar que la actualización es correcta, compruebe si la actualización se ha realizado correctamente:
Asegúrese de que los procesos que se estén ejecutando usen los nuevos binarios. Compruebe lo siguiente en todos los nodos de HADB:
new path/bin/ma -v new path/bin/hadbm -v |
Compruebe si se está ejecutando la base de datos. El siguiente comando debería mostrar que todos los nodos de HADB se están “ejecutando”.
new path/bin/hadbm status -n |
Asegúrese de que los productos que usen HADB hayan cambiado sus punteros para que señalen a la nueva ruta de HADB.
Los productos que usan HADB pueden ejecutar sus pruebas de actualización para verificar que la actualización de HADB también está funcionando.
Después de realizar una actualización en línea, si la nueva versión no funciona correctamente, vuelva a usar la versión anterior de HADB. Sin embargo, si ha habido un cambio en el repositorio del agente de administración, será posible volver a una versión anterior de HADB, pero el nuevo agente de administración deberá estar ejecutándose.
En este apartado se incluye información adicional acerca de la actualización y la implementación de HADB.
El dispositivo de almacenamiento, y los archivos de registro y de historial de los discos sólo locales no utilizan sistemas de archivos montados de forma remota.
Si hay más de un nodo en un host, se recomienda que los dispositivos de cada nodo estén en discos diferentes. De lo contrario, la contención del disco podría reducir el rendimiento. Los indicios de este problema se pueden ver en los archivos del historial mediante mensajes como, por ejemplo, BEWARE - last flush/fputs took too long (ATENCIÓN: los últimos vaciados/entradas tardaron demasiado tiempo). Cuando un único nodo tiene más de un archivo de dispositivos de datos, se recomienda usar distintos discos para dichos archivos de dispositivos.
Use los discos locales (preferiblemente discos separados de los que se usan para los dispositivos de datos) para instalar binarios de HADB en los hosts de HADB. La contención del disco o los retrasos de NFS podrían provocar que se reinicie el nodo, con el mensaje de advertencia, "Process blocked for nnn, max block time is nnn" (Proceso bloqueado durante nnn; tiempo máximo de bloqueo, nnn) en los archivos del historial.
No coloque los dispositivos de HADB, los archivos de historial, los directorios del agente de administración y los archivos de configuración del agente en la ruta del paquete HADB. Esto causará problemas en el momento de actualizar a nuevas versiones y de eliminar la ruta del paquete antiguo.
Esta versión de HADB se admite para un máximo de 28 nodos; 24 de ellos activos y 4 de reserva.
Se recomienda utilizar la misma versión para el controlador JDBC y para el servidor HADB.
No se admite el uso de IPv6, sólo de IPv4.
La longitud de la línea de comandos en Windows está restringida a 2048 bytes.
La red debe configurarse para la multidifusión UDP.
Debido al excesivo intercambio observado en las actualizaciones 1 a 3 de RedHat Enterprise Linux 3.0, no se recomienda su uso como plataforma de implementación. Este problema se ha solucionado en RedHat Enterprise Linux 3.0 Update 4.
Posibilidad de ejecutar NSUP con prioridad de tiempo real.
Los procesos (clu_nsup_srv ) del supervisor de nodos (NSUP) garantizan la alta disponibilidad de HADB con ayuda del intercambio de mensajes de latidos (heartbeat) de una forma periódica. La temporización se ve afectada cuando se utiliza NSUP con otros procesos provocando la aniquilación del recurso. La consecuencia es una falsa partición de la red y que el nodo se reinicia precedido de una advertencia “Process blocked for n seconds” (Proceso bloqueado durante x segundos) en los archivos del historial, lo que da como resultado transacciones canceladas y otras excepciones.
Para solucionar este problema, clu_nsup_srv (que se encuentra en installpath/lib/server) debe tener el conjunto de bits suid y el archivo debe ser propiedad del usuario root. Esto se consigue de forma manual mediante los comandos:
# chown root clu_nsup_srv # chmod u+s clu_nsup_srv |
Esto hace que el proceso clu_nsup_srv se ejecute como el usuario root cuando se inicia y esto, a su vez, permite que el proceso se asigne a sí mismo automáticamente prioridad de tiempo real después del inicio. Para evitar cualquier repercusión negativa en la seguridad usando setuid, la prioridad en tiempo real se define al principio y el proceso retrocede al UID efectivo una vez que se haya cambiado la prioridad. Otros procesos de HADB disminuirán su prioridad a un tipo de prioridad de tiempo compartido.
Si NSUP no pudo definir la prioridad de tiempo real, se emite una advertencia: “Could not set realtime priority” (No se pudo establecer una prioridad de tiempo real) (unix: errno will be set to EPERM), que se escribe en el archivo ma.log y se continúa sin prioridad de tiempo real.
Hay casos en los que no es posible establecer prioridades de tiempo real, por ejemplo:
Cuando la instalación se ha efectuado en zonas no globales de Solaris 10
Cuando los privilegios PRIV_PROC_LOCK_MEMORY (Permitir que un proceso bloquee páginas en la memoria física) y/o los privilegios PRIV_PROC_PRIOCNTL se han revocado en Solaris 10
Los usuarios desactivan los permisos setuid
Los usuarios instalan el software como archivos tar (opción de instalación nonroot para App.server)
El proceso clu_nsup_srv no requiere recursos de la CPU, su huella es pequeña y si se ejecuta con prioridad de tiempo real no repercutirá en el rendimiento.
Configuración de rutas múltiples de red IP para HADB para Solaris (se ha probado sólo en Solaris 9).
Sun recomienda que los hosts de Solaris que ejecutan HADB se configuren con rutas múltiples de red para garantizar la mayor disponibilidad posible de la red. La configuración de las rutas múltiples de red se describe detalladamente en IP Network Multipathing Administration Guide. Si opta por usar rutas múltiples con HADB, consulte el apartado sobre administración de rutas múltiples de IP Network Multipathing Administration Guide para configurar las rutas múltiples antes de continuar con la adaptación de la configuración de rutas múltiples para HADB, tal y como se describe más abajo. IP Network Multipathing Administration Guide forma parte de la colección de documentación relacionada con el administrador de sistemas de Solaris 9 y se puede descargar desde http://docs.sun.com.
Establecimiento del tiempo de detección de fallos de la interfaz de red
Para que HADB sea compatible con la conmutación por error de rutas múltiples, el tiempo de detección de fallos de la interfaz de red no debe superar los 1000 milisegundos, tal y como especifica el parámetro FAILURE_DETECTION_TIME en /etc/default/mpathd. Edite el archivo y cambie el valor de este parámetro a 1000 si el valor original es superior:
FAILURE_DETECTION_TIME=1000 |
Para que el cambio surta efecto, ejecute el siguiente comando:
pkill -HUP in.mpathd |
Direcciones IP que se deben usar con HADB
Tal y como se describe en Solaris IP Network Multipathing Administration Guide, las rutas múltiples suponen la agrupación de interfaces de red físicas en grupos de interfaces con rutas múltiples. Cada interfaz física en un grupo de este tipo cuenta con dos direcciones IP asociadas: una dirección de interfaz física y una dirección de prueba. Para transmitir datos, sólo se puede usar la dirección de interfaz física, mientras que la dirección de prueba es sólo para uso interno de Solaris. Cuando se ejecuta hadbm create --hosts, cada host debe especificarse sólo con una dirección de interfaz física desde el grupo de rutas múltiples.
Ejemplo
Supongamos que el host 1 y el 2 tienen dos interfaces de red físicas cada uno de ellos. En cada host, estas dos interfaces están configuradas como grupos de rutas múltiples y están ejecutando ifconfig -a, por lo que se obtiene lo siguiente:
Host 1
bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000 broadcast 129.159.115.255 |
Host 2
bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000 broadcast 129.159.115.255 |
Aquí, las interfaces de red de los dos hosts son las que aparecen como bge0 y bge1. Las que aparecen como bge0:1 y bge1:1 son las interfaces de prueba de rutas múltiples (por lo tanto, están marcadas como DEPRECATED [en desuso] en el resultado de ifconfig), tal y como se describe en IP Network Multipathing Administration Guide.
Para configurar HADB en este entorno, seleccione una dirección de interfaz física de cada host. En este ejemplo, elegimos 129.159.115.10 del host 1 y 129.159.115.20 del host 2. Para crear una base de datos con un nodo de base de datos por host, use el siguiente argumento para hadbm create:
--host 129.159.115.10,129.159.115.20 |
Para crear una base de datos con dos nodos de base de datos en cada host, use el siguiente argumento:
--host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20 |
En ambos casos, la variable ma.server.mainternal.interfaces de los dos hosts debe establecerse en 129.159.115.0/24.
No es posible actualizar en línea de 4.2 ó 4.3 a 4.4. Sin embargo, la versión 4.4 admite actualizaciones en línea para las versiones futuras. Para actualizar de 4.4.1 a 4.4.2, lleve a cabo los siguientes pasos:
Instale 4.4.2 en todos los hosts de HADB (en una ruta distinta de 4.4.1, por ejemplo en /opt/SUNWhadb/4.4.2-6).
Instale la nueva versión en los hosts hadbm client.
Detenga todos los agentes de administración que se estén ejecutando en los hosts de HADB.
Inicie los procesos del agente de administración usando el software de la nueva versión, pero con los archivos de configuración antiguos. En los pasos que quedan, utilice el comando hadbm, que se incluye en el directorio bin de la nueva versión.
Registre el paquete en el dominio de administración (el nombre predeterminado del paquete pasa a ser V4.4, por lo que será necesario utilizar otro nombre de paquete para evitar conflictos con los paquetes existentes que tengan el mismo nombre):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2 |
Reinicie la base de datos con la nueva versión (el siguiente comando realiza un reinicio por turnos de los nodos):
hadbm set packagename=V4.4.2 database_name |
Compruebe que la base de datos esté “ejecutándose” (para ello, use el comando hadbm status) y que funcione normalmente atendiendo las transacciones de los clientes.
Si todo está funcionando, la instalación antigua podrá eliminarse posteriormente.
Antes de anular el registro del paquete antiguo, elimine todas las referencias a él del repositorio ma. De lo contrario, hadbm unregisterpackage fallará y mostrará un error que indica que el paquete está en uso (package in use).Una operación de reconfiguración ficticia, por ejemplo, hadbm set connectiontrace= <same_as_previous_value>, eliminará todas las referencias al paquete antiguo. Ahora, proceda a anular el registro del paquete antiguo:
hadbm unregisterpackage [--hosts=<host_list>] <old_package_name> |
Elimine la instalación antigua del sistema de archivos, tal y como se describe en las installation instructions de HADB.
No se puede crear un índice secundario UNIQUE en una tabla.
La expresión (DISTINCT column) no está permitida en una expresión agregada, a menos que se trate de la única expresión seleccionada.
Todas las tablas deben crearse con una especificación de clave primaria, es decir, no se pueden usar tablas que no tengan claves primarias.
FULL OUTER JOIN no se admite.
Las subconsultas IN que son subconsultas de tablas no se admiten, por ejemplo:
SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP WHERE P#='P2') |
No se admiten otras restricciones distintas de NOT NULL y PRIMARY KEY.
Es posible asignar un nuevo propietario a un recurso. No obstante, cuando se realiza esta acción, los privilegios concedidos al propietario actual no se conceden al nuevo propietario.
No se admite el uso de dos o más subconsultas NOT EXISTS anidadas en las que cada subconsulta no esté directamente relacionada con el nivel externo de las consultas.
No se admiten los privilegios de columnas.
Los constructores de valores de filas se permiten sólo en sentencias VALUES.
Las subconsultas no se aceptan como expresiones de valor en los constructores de valores de filas.
Los siguientes tipos de datos no se pueden usar cuando se crean claves primarias:
REAL
FLOAT
DOUBLE PRECISION
DECIMAL
NUMERIC
Application Server incluye equilibrado de carga para los clientes HTTP, IIOP y JMS; compatibilidad con conmutación por error de sesión HTTP; compatibilidad con la agrupación en clústeres de EJB y los servicios de conmutación por error; temporizadores EJB de alta disponibilidad; recuperación de transacciones distribuida; compatibilidad con actualizaciones de aplicaciones por turnos; y una base de datos de alta disponibilidad para el almacenamiento del estado transitorio de las aplicaciones J2EE.
La disponibilidad hace posible la conmutación por error de las instancias de Application Server en un clúster. Si una instancia de Application Server pasa a estar inactiva, otra instancia de Application Server asumirá las sesiones que estaban asignadas al servidor que ahora no está disponible. La información de sesión se almacena en HADB. HADB es compatible con la persistencia de las sesiones HTTP, los Stateful Session Beans y las credenciales de inicio de sesión único.
En la próxima versión importante de Sun Java System Application Server Edición Enterprise, se producirán las siguientes incompatibilidades:
Aunque el servicio HTTP seguirá utilizando una caché DNS para obtener un mejor rendimiento, no estará disponible la función de supervisión de la caché DNS.
La compatibilidad con el almacenamiento en caché de archivos HTTP se renovará, por lo que producirán cambios en la configuración y la supervisión.
El formato del sufijo de giro del registro de acceso se cambiará por uno compatible con los objetos de fecha y hora, como se especifica en http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html. El valor predeterminado de esta versión, “%YYYY;%MM;%DD;-%hh;h%mm;m%ss;s ,” seguirá siendo compatible, pero no se admitirá ninguna otra variación.
Las propiedades, atributos y los elementos de domain.xml que no se admitan se marcarán como advertencias en el registro del servidor y en el archivo de registro de actualización indicando que están en desuso.
El nodo server.http-service.dns ya no estará disponible en la vista de supervisión.
Es posible que se eliminen algunos atributos del nodo server.http-service.file-cache. Por lo tanto, fallarán todos los comandos de supervisión asadmin que intenten acceder a los atributos eliminados.
La herramienta de implementación ya no estará disponible. Habrá una función equivalente disponible en NetBeans IDE. Para obtener más información, consulte el tutorial J2EE 1.4 para NetBeans 4.1 en http://www.netbeans.org/kb/.
El modo de interfaz gráfica de usuario de Verifier (ejecutado por verifier -u) ya no estará disponible. Habrá una función equivalente disponible en NetBeans IDE.
El modo predeterminado de la verificación de aplicaciones al utilizar la herramienta Verifier cambiará de "Verify J2EE rules" (Verificar reglas de J2EE) a "Verify J2EE rules and Sun Application Server Configuration Rules" (Verificar reglas de J2EE y reglas de configuración de Sun Application Server).En otras palabras, Verifier comprobará de forma predeterminada si la aplicación cumple las reglas de J2EE y si está configurada para ejecutarse en Sun Application Server. El comando verifier incluirá un conmutador de línea de comandos para comprobar si una aplicación cumple sólo las reglas de J2EE.
En la versión actual, las entradas de directorio y JAR agregadas a los atributos classpath-prefix , server-classpath y classpath-suffix de domain.xml (archivo de configuración de Application Server) están disponibles en la ruta de clase del sistema JVM. Una aplicación que dependa de este comportamiento puede utilizar los siguientes métodos de la clase java.lang.ClassLoader para acceder a las clases o a otros recursos desde la ruta de clase del sistema JVM:
getSystemClassLoader()
getSystemResource()
getSystemResourceAsStream()
getSystemResources
En la siguiente versión importante, las entradas de directorio y JAR agregadas a classpath-prefix, server-classpath y classpath-suffix no estarán disponibles en la ruta de clase del sistema JVM. Si una aplicación utiliza uno de los métodos mencionados anteriormente, Sun recomienda encarecidamente el uso de un método equivalente que no presuponga que los recursos estén disponibles en la ruta de clase del sistema. Los métodos equivalentes que no utilizan la ruta de clase del sistema JVM están disponibles en java.lang.ClassLoader y deberían utilizarse siempre que sea posible como, por ejemplo, en el siguiente caso:
java.net.URL url = ClassLoader.getSystemResource ("com/acme/tools/tools.properties");
java.net.URL url = this.getClass().getClassLoader().getResource ("com/acme/tools/tools.properties");
Si no se puede cambiar el código, es recomendable utilizar la nueva opción de configuración que se agregará en la próxima versión y que se utiliza para definir la ruta de clase del sistema JVM.
La seguridad para los servicios web puede configurarse con los archivos wss-client-config.xml y wss-server-config.xml. Tenga en cuenta que el contenido y los nombres de estos archivos de configuración no son estables, y es muy probable que cambien. La funcionalidad equivalente seguirá estando disponible.
Sun Java System Application Server Edición Enterprise 8.2 es compatible con la plataforma J2EE 1.4. La siguiente tabla describe las API mejoradas que están disponibles en la plataforma J2EE 1.4.
Tabla 2–5 API disponibles en la plataforma J2EE 1.4
API |
Descripción |
Componentes de |
|
Aplicación y cliente de la aplicación |
Aplicación de descriptores de implementación estándar mediante esquemas XML |
Enterprise JavaBeans (EJB) 2.1 |
Servicio de temporizadores y punto final del servicio web EJB |
Java Servlet 2.4 |
Filtro de punto final del servicio web |
Arquitectura JavaServer Pages (JSP) 2.0 |
Lenguaje de expresiones y biblioteca de etiquetas |
J2EE Connector Architecture 1.5 |
Conectividad con adaptador de recursos entrantes y Java Message Service (JMS) |
Servicios web |
|
Java Web Services Developer Pack 1.5 |
Paquete de herramientas integrado para crear, probar e implementar aplicaciones XML y servicios y aplicaciones web |
Java API for XML-based Remote Procedure Calls (JAX-RPC) 1.1 |
Asignación para WSDL y tecnología Java y compatibilidad con el desarrollo de puntos finales y clientes de servicios web |
WS-I Basic Profile 1.0 |
Elemento que activa la interoperabilidad usando WSDL y SOAP |
SOAP with attachment API for Java (SAAJ) 1.2 |
Una API para mensajes basados en SOAP; hace posible la creación de mensajes SOAP con archivos adjuntos |
Java APIs for XML Registries (JAXR) 1.0 |
Una API estándar y uniforme para acceder a los registros XML como, por ejemplo, el servicio de descubrimiento e integración de descripciones universales, Universal Description Discovery and Integration (UDDI y ebXML) |
Otro |
|
J2EE Deployment 1.1 |
API estándar que hace posible la implementación de aplicaciones y componentes J2EE |
J2EE Management 1.0 |
Definiciones para el modelo de información destinadas a gestionar la plataforma J2EE |
Java Management Extensions (JMX) 1.2 |
API de gestión estándar |
Java Authorization Contract for Containers (JACC) 1.0 |
Definiciones de los contratos de seguridad establecidos entre J2EE Application Server y el proveedor de directivas de autorizaciones |
Java API for XML Processing (JAXP) 1.2 |
Una API mediante la cual las aplicaciones pueden analizar y transformar documentos XML. También agrega compatibilidad con el procesamiento de esquemas XML |
JMS 1.1 |
Un estándar de mensajería que hace posible que los componentes de aplicación de J2EE creen, envíen y lean mensajes. También agrega compatibilidad con API uniformes para colas y tema. |
JavaMail 1.3 |
Conjunto de clases abstractas que sirven de modelo para un sistema de correo. También incluye actualizaciones menores para las API. |
Sun Java System Application Server 8.2 requiere J2SE 5.0 o superior como JVM subyacente. Si desea cambiar de una versión de Java a otra, lleve a cabo los siguientes pasos generales. (Windows y Unix)
Descargue Java SDK (no JRE) e instale este componente en el sistema, si todavía no lo ha hecho.
Java SDK puede descargarse desde http://java.sun.com/j2se.
Detenga por completo Application Server.
Puede utilizar la siguiente línea de comandos:
as-install/bin/asadmin stop-domain |
También puede utilizar la GUI de la consola de administración:
Edite el archivo install_dir/config/asenv.conf (asenv.bat en Windows) cambiando el valor de AS_JAVA para que señale al nuevo directorio de inicio de J2SE.
Edite el archivo as-install/samples/common.properties cambiando la línea que comienza por com.sun.aas.javaRoot... para que haga referencia al nuevo directorio de inicio de J2SE.
Reinicie Application Server.
as-install/bin/asadmin start-domain |
Application Server incluye un contenedor EJB de alto rendimiento, servicios y un contenedor web, y admite el envío simultáneo de mensajes con el software Sun Java System Message Queue.
Application Server admite una escalabilidad horizontal mediante el agrupamiento (clúster) de las instancias de servidor y el equilibrado de carga de las solicitudes. También alcanza una escalabilidad vertical de clases gracias a su compatibilidad con equipos de gran tamaño y con varios procesadores. El agente de mensajes integrado se puede agrupar en clúster para obtener una mejor disponibilidad y escalabilidad. En el acceso de cliente desde clientes HTTP, aplicaciones de clientes enriquecidos basados en RMI/IIOP, clientes de servicios web y clientes JRM se puede efectuar un equilibrado de carga hacia los clústeres de Application Server.
Sun Java System Application Server Edición Enterprise 8.2 es compatible con la tecnología JavaServer Faces 1.1. La tecnología JavaServer Faces consiste en una serie de API de servidor que representan a los componentes de la interfaz de usuario que administran la validación de las entradas, la gestión, los eventos y el estado. Las API también determinan la navegación por la página y admiten funciones de accesibilidad e internalización. Puede agregar componentes personalizados de la interfaz de usuario con una biblioteca de etiquetas JSP personalizada.
Al desarrollar con la tecnología JavaServer Faces, cada miembro del equipo de desarrollo se puede centrar en un único aspecto del proceso. Un único modelo de programación sirve de vínculo entonces para los distintos fragmentos, lo que da como resultado un ciclo de desarrollo mucho más sencillo y eficaz.