Cambios en Edge para la nube privada 4.54.00

Descripción general de los cambios

Edge para nube privada 4.54.00 presenta varios cambios que mejoran la postura de seguridad de la plataforma y actualiza los componentes de la plataforma para que se ejecuten con Java 21. Dos de las siguientes secciones abarcan estos cambios:

• Cambios en la política de texto destacado de Java
• Cambios en TLS y en el conjunto de algoritmos de cifrado

Además de estos cambios, revisa la guía de la herramienta de detección de cambios específica. Esta utilidad se puso a disposición para identificar cambios en los proxies, los flujos compartidos o cualquier otro artefacto de tu clúster que pueda causar interrupciones como resultado de esta actualización.

Cambios en la política de Java Callout

En Edge para nube privada 4.54.00, los componentes principales de la plataforma, incluidos el Message Processor, el servidor de administración y el router, se actualizaron para ejecutarse en Java 21 LTS. Java 21 moderniza la plataforma de Java, lo que incluye quitar los módulos heredados de Java EE y CORBA (JEP 320), quitar las clases de utilidad internas heredadas y aplicar una encapsulación modular sólida (JEP 403).

Debido a estos cambios, los proxies de API con políticas de JavaCallout personalizadas o JAR de recursos personalizados (almacenados a nivel del proxy, el entorno o la organización) pueden experimentar interrupciones cuando se actualicen a la versión 4.54.00.

Categorías de cambios que pueden afectar las llamadas de código Java

1. Se quitaron de forma permanente los módulos de Java EE y CORBA (JEP 320): Los módulos que antes se integraban en el entorno de ejecución de Java 8 (incluidos JAXB javax.xml.bind.*, JAF javax.activation.*, JAX-WS javax.xml.ws.* y CORBA org.omg.*) se quitaron de Java SE. Los textos destacados que hacen referencia a estos paquetes sin incluir reemplazos independientes fallan durante el tiempo de ejecución con NoClassDefFoundError.
2. Se quitaron las clases de utilidad internas: Se quitaron los asistentes internos heredados, como sun.misc.BASE64Encoder y sun.misc.BASE64Decoder. Las llamadas a estas clases fallan con NoClassDefFoundError.
3. Encapsulación sólida de los elementos internos de Java (JEP 403): No se puede acceder de forma reflexiva a los paquetes internos de java.base (como sun.security.*, sun.reflect.* y com.sun.*) desde las leyendas personalizadas. Las llamadas reflectivas fallan en el tiempo de ejecución con InaccessibleObjectException.
4. Modificaciones y eliminaciones de firmas de métodos en las clases de Java que se conservan: En ciertos módulos de Java, la clase sigue presente en Java 21, pero se quitaron, se marcaron como obsoletos o se modificaron constructores o firmas de métodos específicos (como métodos de análisis de DOM específicos en org.w3c.dom.Document y clases de análisis de XML relacionadas).

   Detección de herramientas: La herramienta de detección de cambios marca las referencias a estas clases en la categoría METHOD_SIGNATURE_MODIFICATION con MEDIUM de certeza de impacto, lo que solicita a los desarrolladores que inspeccionen el código fuente de sus textos destacados para buscar invocaciones de métodos modificadas.

Estrategias de corrección

Antes de actualizar, asegúrate de que tus políticas de Java Callout y recursos JAR personalizados sean compatibles con el tiempo de ejecución de Java 21. Usar la herramienta de detección de cambios te ayudará a identificar los proxies de API, los flujos compartidos y los recursos JAR de la organización o el entorno afectados en todo tu clúster.

Las estrategias de solución descritas en esta sección son guías generales y no se excluyen mutuamente. Según tus requisitos operativos, puedes combinar estrategias, por ejemplo, modernizar el código fuente de las llamadas con la Estrategia 2 y, luego, implementar las revisiones de proxy actualizadas con la Estrategia 3B para lograr un tiempo de inactividad cero durante las actualizaciones de Message Processor.

Las estrategias 3A, 3B y 3C son tres formas de llevar a cabo el mismo enfoque operativo: actualizar el nodo y volver a implementar el proxy en diferentes momentos, sin cambiar el paquete del proxy. Elige una o una combinación de estas opciones según tus requisitos de disponibilidad de la API.

Revisa la siguiente guía de decisiones para seleccionar el enfoque más adecuado para tu implementación:

Guía de decisiones para las mitigaciones de las llamadas de código Java:

Estrategia 1: Proxy con compatibilidad doble a través de JAR empaquetados (prueba antes de actualizar para que no haya tiempo de inactividad)

Cuándo usarla: Usa esta estrategia en los siguientes casos:

• Hay una biblioteca de reemplazo independiente con compatibilidad doble disponible: Existe un JAR de reemplazo que implementa la funcionalidad requerida y se puede empaquetar directamente en tu proxy de API sin necesidad de modificar el código fuente.
• Deseas que tus proxies de API y textos destacados de Java existentes funcionen sin problemas tanto en tu versión actual (por ejemplo, Edge para nube privada 4.53.01) como en la versión actualizada (Edge para nube privada 4.54.00).
• Te recomendamos probar y verificar todos los cambios en tus entornos de producción y de pruebas antes de actualizar tu clúster de Edge para la Nube privada, lo que garantiza que no haya problemas inesperados ni tiempo de inactividad en el tráfico en vivo.
• Quieres evitar volver a escribir o refactorizar la lógica empresarial de la llamada de código Java.

Cómo funciona: En Java 8, ciertas bibliotecas (como JAXB javax.xml.bind.* o Activation javax.activation.*) se integraban directamente en el entorno de ejecución de Java 8. Por este motivo, los desarrolladores no necesitaban incluir archivos JAR adicionales dentro de sus paquetes de proxy. En Java 21, estas bibliotecas se quitaron del tiempo de ejecución de Java.

Para que tu proxy sea "compatible con ambos" en Edge para nube privada 4.53.x y 4.54.00, haz lo siguiente:

1. Identifica la biblioteca faltante que requiere tu texto destacado (por ejemplo, JAXB o Activation).
2. Adquiere el archivo JAR de reemplazo de código abierto independiente (por ejemplo, jakarta.xml.bind-api-2.3.3.jar y jaxb-runtime-2.3.8.jar).
3. Coloca el JAR de reemplazo directamente en el paquete de proxy en apiproxy/resources/java/, súbelo a la revisión del proxy con la API de archivos de recursos a nivel de proxy o súbelo como un archivo de recursos en el nivel de entorno o nivel de organización. Para obtener más información sobre la administración de archivos de recursos, consulta la documentación de archivos de recursos de Apigee.
4. Implementa y prueba antes de la actualización: Los Message Processors en Edge para nube privada 4.53.x y 4.54.00 cargan clases desde estos archivos JAR incluidos. Puedes implementar este paquete de proxy actualizado y probarlo con tráfico sintético en tu clúster actual de Edge para nube privada 4.53.x ahora.
5. Habilita la carga de paquetes externos permitidos en los Message Processors (obligatorio para la versión 4.54.00): De forma predeterminada, en Edge para nube privada 4.54.00, la carga de paquetes de Java quitados (como javax.xml.bind.* y javax.activation.*) desde JAR de recursos externos o empaquetados está inhabilitada (conf_system_java.21.enable.external.allowed.packages=false), por lo que empaquetar los JAR por sí solos no funcionará de forma predeterminada. Debes habilitar esta propiedad en /opt/apigee/customer/application/message-processor.properties con código con configuración (CwC) (puedes configurar esta propiedad antes de actualizar el nodo Message Processor o establecerla después de la actualización y reiniciar el Message Processor):

   conf_system_java.21.enable.external.allowed.packages=true

6. Cero problemas de tráfico en vivo después de la actualización: Cuando tu clúster se actualice posteriormente a Edge para nube privada 4.54.00 con conf_system_java.21.enable.external.allowed.packages=true habilitado, el Message Processor ya tendrá disponible el JAR requerido y cargará las clases desde el archivo de recursos empaquetado sin fallas (NoClassDefFoundError), lo que garantizará una actualización sin problemas y sin tiempo de inactividad.

Ejemplo de código: Llamada de validación y análisis de XML de pedidos

Considera un Callout de Java de Apigee típico que extrae y valida pedidos XML entrantes con JAXB (JAXBContext y Unmarshaller).

• Antes de la corrección (falla en Edge para nube privada 4.54.00): En Edge para nube privada 4.53.x, el paquete de proxy contiene solo el JAR de texto destacado, que se basa en las bibliotecas de entorno de ejecución de Java 8 integradas para JAXB:

  apiproxy/
    resources/
      java/
        OrderXmlParserCallout.jar   <-- No JAXB JAR bundled

  La implementación de la llamada de código Java:

  package com.example.callout;
  
  // other required imports
  import java.io.StringReader;
  import javax.xml.bind.JAXBContext;
  import javax.xml.bind.Unmarshaller;
  
  public class OrderXmlParserCallout implements Execution {
      @Override
      public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
          try {
              String requestXml = messageContext.getMessage().getContent();
              JAXBContext jaxbContext = JAXBContext.newInstance(Order.class);
              Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
              Order order = (Order) unmarshaller.unmarshal(new StringReader(requestXml));
              messageContext.setVariable("order_id", order.getId());
              return ExecutionResult.SUCCESS;
          } catch (Exception e) { }
      }
  }

  La falla: En Edge para nube privada 4.53.x, esto se ejecuta sin problemas. Una vez que el nodo se actualiza a Edge para la nube privada 4.54.00, este proxy falla de inmediato durante el procesamiento de la solicitud:

  java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
          at com.example.callout.OrderXmlParserCallout.execute(OrderXmlParserCallout.java:20)

• Después de la corrección (compatibilidad doble en Edge para la nube privada 4.53.x y 4.54.00): No es necesario que vuelvas a escribir ni a compilar el código de llamada de código Java. Puedes hacer que tu proxy sea compatible con ambos entornos directamente proporcionando los archivos JAR independientes:
  1. Incluye o sube directamente los archivos JAR independientes: Obtén las bibliotecas JAXB independientes (jakarta.xml.bind-api-2.3.3.jar y jaxb-runtime-2.3.8.jar) y colócalas dentro del paquete del proxy en apiproxy/resources/java/:

     apiproxy/
       resources/
         java/
           OrderXmlParserCallout.jar
           jakarta.xml.bind-api-2.3.3.jar
           jaxb-runtime-2.3.8.jar

     Como alternativa, sube jakarta.xml.bind-api-2.3.3.jar y jaxb-runtime-2.3.8.jar como archivos de recursos con la API de archivos de recursos a nivel del proxy, o bien a nivel del entorno o nivel de la organización para que todos los proxies en el mismo alcance puedan compartirlos sin incluirlos en cada paquete de proxy individual.

     Si compilas tu paquete de proxy desde la fuente con Maven, declara estas dependencias en tu pom.xml para que se empaqueten automáticamente durante la compilación.

  2. Implementa y prueba en tu clúster 4.53.x actual: Implementa el paquete de proxy actualizado en tu entorno existente de Edge para nube privada 4.53.x y envía llamadas de prueba. Dado que los Message Processors de Edge para nube privada 4.53.x cargan clases desde estos archivos JAR incluidos, puedes verificar que la devolución de llamada siga funcionando de forma idéntica.
  3. Habilita la carga de paquetes externos permitidos a través de CwC: Debido a que la carga de paquetes externos permitidos está inhabilitada de forma predeterminada en Edge para nube privada 4.54.00 (conf_system_java.21.enable.external.allowed.packages=false), habilítala en cada nodo de Message Processor en /opt/apigee/customer/application/message-processor.properties con el código con configuración (CwC):

     conf_system_java.21.enable.external.allowed.packages=true

  4. Cero problemas de tráfico en vivo después de la actualización: Una vez validado en tu entorno 4.53.x y configurado con la propiedad CwC, tu proxy estará completamente preparado. Cuando actualizas tu clúster a Edge para nube privada 4.54.00, el Message Processor carga las clases JAXB incluidas, lo que garantiza cero errores y cero interrupciones del tráfico en vivo.

Estrategia 2: Implementación alternativa (modernización de código y dependencias)

Cuándo usarlo: Se recomienda para bases de código activas en las que el código fuente del proxy se mantiene fácilmente. Este es el enfoque más limpio a largo plazo para cumplir con Java 21. Nota de lanzamiento: Debido a que la implementación de revisiones de proxy modernizadas requiere la coordinación del Message Processor, combina esta estrategia con la estrategia 3A (durante un período de mantenimiento planificado) o la estrategia 3B (para lograr un tiempo de inactividad cero con Message Processors paralelos).

Cómo funciona: Reemplaza las clases internas de Java que se quitaron con las APIs oficiales estándar de Java SE o con equivalentes independientes de código abierto, y empaqueta las dependencias externas requeridas directamente en los archivos de recursos o en el POM del paquete del proxy.

Ejemplos de código:

Ejemplo 1: Modernización de métodos y código (reemplazo de utilidades internas quitadas)

En Java 8, los callouts suelen usar clases de utilidad internas, como sun.misc.BASE64Encoder. En Java moderno, se quitaron estas clases, pero la API de java.util.Base64 estándar proporciona reemplazos directos sin necesidad de archivos JAR de dependencia externos:

• Antes (implementación heredada de Java 8):

  // Incompatible in Edge for Private Cloud 4.54.00: sun.misc package removed
  import sun.misc.BASE64Encoder;
  // other required imports
  
  public class Base64EncodeCallout implements Execution {
      @Override
      public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
          BASE64Encoder encoder = new BASE64Encoder();
          String encoded = encoder.encode("ApigeePayload".getBytes());
          messageContext.setVariable("encoded_data", encoded);
          return ExecutionResult.SUCCESS;
      }
  }

• Después (implementación compatible con Java 21):

  // Fully compatible with Java 21: uses standard Java SE java.util.Base64 (no external JARs needed)
  import java.util.Base64;
  // other required imports
  
  public class Base64EncodeCallout implements Execution {
      @Override
      public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
          String encoded = Base64.getEncoder().encodeToString("ApigeePayload".getBytes());
          messageContext.setVariable("encoded_data", encoded);
          return ExecutionResult.SUCCESS;
      }
  }

Ejemplo 2: Refactorización a nivel de la importación con biblioteca agrupada (JAXB Namespace Prefix Mapper)

En Java 8, los proxies de API que personalizaban los prefijos de espacios de nombres XML solían extender el asignador JAXB interno de Sun com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper. En Java 21, se quitan los paquetes internos de Sun y no se puede acceder a ellos.

La biblioteca de código abierto independiente (org.glassfish.jaxb:jaxb-runtime) proporciona la clase idéntica en com.sun.xml.bind.marshaller.NamespacePrefixMapper. Todas las firmas de métodos, los parámetros y los tipos de datos que se devuelven son idénticos. El cambio de código se encuentra estrictamente en la instrucción de importación:

• Antes (implementación heredada de Java 8):

  // In Java 8: Relied on internal Sun class in Java 8 runtime
  import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper;
  public class CustomNamespaceMapper extends NamespacePrefixMapper {
      @Override
      public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
          if ("http://schemas.example.com/orders".equals(namespaceUri)) {
              return "ord";
          }
          return suggestion;
      }
  }

• Después (implementación compatible con Java 21):

  // In Java 21: Identical methods and logic; ONLY the import statement changes (".internal." removed)
  import com.sun.xml.bind.marshaller.NamespacePrefixMapper;
  public class CustomNamespaceMapper extends NamespacePrefixMapper {
      @Override
      public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
          if ("http://schemas.example.com/orders".equals(namespaceUri)) {
              return "ord";
          }
          return suggestion;
      }
  }

• Configuración de dependencias empaquetadas (pom.xml): Para proporcionar esta clase en el entorno de ejecución, empaqueta las bibliotecas de JAXB independientes dentro de apiproxy/resources/java/ o decláralas en tu pom.xml:

  <dependencies>
      <!-- Standalone JAXB API for Java 21 -->
      <dependency>
          <groupId>jakarta.xml.bind</groupId>
          <artifactId>jakarta.xml.bind-api</artifactId>
          <version>2.3.3</version>
      </dependency>
      <!-- Standalone JAXB Runtime providing com.sun.xml.bind.marshaller.NamespacePrefixMapper -->
      <dependency>
          <groupId>org.glassfish.jaxb</groupId>
          <artifactId>jaxb-runtime</artifactId>
          <version>2.3.8</version>
      </dependency>
  </dependencies>

Estrategia 3A: Tiempo de inactividad por mantenimiento planificado (redistribución in situ)

Cuándo usarlo: Se recomienda para entornos con períodos de mantenimiento operativo programados en los que se acepta una breve interrupción del servicio.

Procedimiento:

1. Coordina un período de mantenimiento programado con los consumidores de la API.
2. Actualiza tus componentes de Edge para nube privada a la versión 4.54.00 siguiendo la guía de rutas de actualización.
3. Implementa la revisión precompilada y compatible con la versión 4.54.00 de tu proxy de API con la nueva IU de Edge o la API de Apigee Management (Deployments).
4. Verifica la ejecución de las llamadas enviando solicitudes de prueba sintéticas a los Message Processors y, luego, inspecciona los registros con la herramienta Trace.
5. Cierra el período de mantenimiento y vuelve a abrir el tráfico público.

Estrategia 3B: Crea un entorno nuevo (migración sin tiempo de inactividad)

Cuándo usarla: Se recomienda para entornos de producción esenciales que requieren cero tiempo de inactividad. Usa esta opción cuando no se pueda actualizar la llamada de código Java para que funcione en Java 8 y Java 21 de forma simultánea.

Cómo funciona: Esta estrategia implica adquirir uno o más entornos nuevos para que puedas conectar nodos de Message Processor de diferentes versiones. Luego, implementa proxies compatibles con Java 8 en el entorno conectado con Message Processors 4.53.X y proxies compatibles con Java 21 en el entorno conectado con Message Processors 4.54.00. Luego, usa un balanceador de cargas o alguna otra técnica de enrutamiento para dirigir el tráfico solo al proxy compatible con Java 21.

Para esta estrategia, comprender cómo interactúan las organizaciones, los entornos y los Message Processors es clave para una migración de sistemas sin tiempo de inactividad (para obtener más información, consulta Estructura de la organización de Apigee Edge):

• Una organización de Apigee es un límite administrativo de nivel superior que contiene varios entornos (por ejemplo, prod, test).
• Se implementa una revisión de proxy de API en un entorno específico. Solo los Message Processors vinculados de forma explícita a ese entorno cargan y ejecutan la revisión del proxy.

+------------------------------------------------------------------------+
|                          Apigee Organization                           |
|                                                                        |
|  Existing Environment (prod)            Temporary Env (prod-migration) |
|  +--------------------------------+     +----------------------------+ |
|  | Current 4.53.01 MP Nodes       |     | New 4.54.00 MP Nodes       | |
|  |               |                |     |              |             | |
|  | Proxy Rev N (4.53.01)          |     | Proxy Rev N+1 (Modernized) | |
|  +--------------------------------+     +----------------------------+ |
+------------------------------------------------------------------------+
                   ^                                    ^
                   | Step 1: Normal Live                | Step 2: Canary
                   |         Traffic (prod)             | Step 3: Complete
          +------------------------------------------------------+
          |       Upstream Load Balancer / Ingress Router        |
          +------------------------------------------------------+

Procedimiento:

1. Crea un entorno temporal: Crea un entorno nuevo (por ejemplo, prod-migration) dentro de tu organización (siguiendo Configura hosts y entornos virtuales) con un host y un puerto virtuales dedicados.
2. Aprovisiona nodos de Message Processor 4.54.00: Instala Edge para nube privada 4.54.00 en instancias de VM nuevas o temporales, y vincula estos nodos a prod-migration (consulta Agrega un Message Processor).
3. Identifica los proxies afectados y crea revisiones actualizadas: Identifica los proxies de API que usan llamadas de código Java (con la herramienta de detección de cambios) y crea una revisión nueva de cada proxy afectado con llamadas de código Java compatibles con Edge para nube privada 4.54.00 (aplicando la estrategia 1 o la estrategia 2).
4. Implementa las revisiones de proxy modernizadas en el entorno temporal: Implementa las revisiones de proxy actualizadas y compatibles exclusivamente en prod-migration.
5. Verifica y cambia el tráfico: Ejecuta pruebas de verificación sintéticas en el nuevo host virtual. Una vez que se verifique, configura tu balanceador de cargas externo (F5, NGINX) para redireccionar el tráfico del cliente de prod a prod-migration.
6. Actualiza los nodos originales y vuelve a cambiar: Anula la implementación de los proxies heredados de prod. Actualiza los nodos de Message Processor originales a la versión 4.54.00 siguiendo la guía de rutas de actualización. Implementa las revisiones de proxy modernizadas en prod, redirecciona el tráfico del balanceador de cargas de vuelta a prod y verifica la operación.
7. Retira el entorno temporal: Anula la implementación de los proxies de prod-migration, quita los nodos de Message Processor temporales y borra el entorno temporal.

Estrategia 3C: Ubicación de bibliotecas externas a nivel del nodo (bibliotecas de resguardo compartidas)

Cuándo usarla: Se recomienda cuando tienes varios proxies de API que dependen de clases de Java que se quitaron en Java 21, y volver a compilar o empaquetar cada paquete de proxy individual antes de la actualización no es viable desde el punto de vista operativo.

Cómo funciona: En Edge para nube privada 4.54.00, los Message Processors proporcionan un mecanismo para cargar las clases de Java faltantes desde un directorio de nodos dedicado: $APIGEE_ROOT/data/edge-message-processor/external-lib.

Cuando este mecanismo está habilitado, el Message Processor verifica este directorio en busca de clases faltantes antes de recurrir a la resolución predeterminada. Puedes proporcionar las clases faltantes obteniéndolas de JAR de bibliotecas de terceros o empaquetando las clases requeridas en un JAR y colocándolo en external-lib.

Procedimiento:

1. Crea el directorio de la biblioteca externa en cada nodo de Message Processor:

   mkdir -p /opt/apigee/data/edge-message-processor/external-lib

2. Coloca los JAR necesarios en el directorio: Copia los archivos JAR que contienen las clases necesarias en /opt/apigee/data/edge-message-processor/external-lib.
3. Establece los permisos de archivo adecuados: Asegúrate de que el usuario del servicio apigee tenga permisos de lectura:

   chown -R apigee:apigee /opt/apigee/data/edge-message-processor/external-lib
   chmod 755 /opt/apigee/data/edge-message-processor/external-lib
   chmod 644 /opt/apigee/data/edge-message-processor/external-lib/*.jar

4. Habilita la carga de paquetes externos en la configuración del Message Processor: De forma predeterminada, en Edge para nube privada 4.54.00, la carga de paquetes externos permitidos está inhabilitada (conf_system_java.21.enable.external.allowed.packages=false). Para permitir que el Message Processor resuelva y cargue clases desde /opt/apigee/data/edge-message-processor/external-lib, debes habilitar esta propiedad en /opt/apigee/customer/application/message-processor.properties con el código con configuración (CwC):

   conf_system_java.21.enable.external.allowed.packages=true

5. Reinicia el procesador de mensajes:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Estrategia 4: Marcas de JVM (--add-opens / --add-exports, con precaución y como último recurso)

Cuándo usarla: Usa esta estrategia como último recurso para las bibliotecas de proveedores externos de código cerrado en las que el código fuente no está disponible, los proveedores no lanzaron actualizaciones de Java 21 y el archivo JAR depende estrictamente del acceso reflexivo a los paquetes internos de Java.

Procedimiento:

1. Identifica el paquete inaccesible que se usa para la reflexión: Determina el módulo y el paquete internos de Java a los que accede tu biblioteca de terceros de forma reflexiva. Nota: Estos errores de reflexión se producen estrictamente en Java 21 en Edge para nube privada 4.54.00 y no aparecerán en los registros de la versión 4.53.x. Verifica los registros del Message Processor (/opt/apigee/var/log/edge-message-processor/system.log) después de la actualización para ver el InaccessibleObjectException que identifica el módulo y el paquete requeridos:

   java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module

2. Edita /opt/apigee/customer/application/message-processor.properties con código con configuración (CwC) (crea el archivo si no existe).
3. Agrega las marcas --add-opens o --add-exports segmentadas a bin_setenv_ext_jvm_opts.

   # Configure targeted JVM module access for closed-source legacy callouts (enclosed in double quotes)
   bin_setenv_ext_jvm_opts="-XX:+UseG1GC -XX:+AlwaysPreTouch --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.misc=ALL-UNNAMED --add-opens java.base/sun.security.util=ALL-UNNAMED --add-opens java.base/sun.security.x509=ALL-UNNAMED"

4. Asegúrate de que la propiedad y los permisos del archivo sean los adecuados:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
   chmod 644 /opt/apigee/customer/application/message-processor.properties

5. Reinicia el Message Processor con apigee-service:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Cambios en TLS y en el conjunto de algoritmos de cifrado

En Edge para nube privada 4.54.00, los componentes principales de la plataforma, incluidos el Message Processor, el servidor de administración y el router, se actualizan para ejecutarse en Java 21 LTS. Esta actualización moderniza la seguridad criptográfica, ya que habilita TLS 1.3 de forma predeterminada (JEP 332). Los Message Processors ahora negocian TLS 1.3 como el protocolo preferido para las conexiones de backend salientes y recurren a TLS 1.2 cuando el backend no lo admite.

Requisitos y corrección de backends heredados

La base criptográfica de Java 21 actualiza la lista de protocolos y conjuntos de algoritmos de cifrado inhabilitados de forma predeterminada en jdk.tls.disabledAlgorithms (como los protocolos TLS heredados y los conjuntos de intercambio de claves RSA estáticos sin secreto directo: TLS_RSA_*). Como proporcionas tu propio entorno de ejecución de Java 21, la lista exacta de protocolos y conjuntos de algoritmos de cifrado inhabilitados depende de tu implementación específica de Java 21.

Si tus proxies de API existentes se conectan a una infraestructura de backend heredada que requiere protocolos inhabilitados o algoritmos de cifrado RSA estáticos, revisa las siguientes acciones:

• Moderniza la seguridad del backend (recomendado): Actualiza los servidores de destino y los balanceadores de cargas para que admitan TLS 1.2 o TLS 1.3 con conjuntos de algoritmos de cifrado ECDHE modernos. Para configurar protocolos y conjuntos de algoritmos de cifrado en tus proxies de API, consulta Configura TLS de Edge al backend y la referencia de configuración de TargetEndpoint de TLS/SSL (o Balanceo de cargas entre servidores de backend si usas TargetServers).
• Vuelve a habilitar los algoritmos heredados con CwC (medida de transición durante la actualización): Si las actualizaciones del backend no se pueden completar antes de la actualización de la plataforma, puedes volver a habilitar temporalmente los algoritmos requeridos con código con configuración (CwC):
  1. Verifica el valor predeterminado de jdk.tls.disabledAlgorithms en tu instalación de Java 21 (por ejemplo, en $JAVA_HOME/conf/security/java.security).
  2. Anula conf_jvmsecurity_jdk.tls.disabledAlgorithms en /opt/apigee/customer/application/message-processor.properties con la misma lista de algoritmos inhabilitados, y quita solo la entrada TLS_RSA_* (mantén intactos todos los demás algoritmos inhabilitados para que sigan habilitadas las protecciones restantes).
  3. Reinicia el Message Processor con apigee-service. Quita esta anulación una vez que el backend admita los conjuntos de algoritmos de cifrado ECDHE.
• Actualiza una lista de entidades permitidas de conjuntos de algoritmos de cifrado personalizados: Si anteriormente anulaste conf_http_HTTPTransport.ssl.cipher.suites.whitelist, revísalo antes de actualizar. Java 21 ya no admite los conjuntos de RSA estáticos (TLS_RSA_*), por lo que una lista de entidades permitidas que solo contenga esos conjuntos deja al Message Processor sin un algoritmo de cifrado utilizable y las llamadas de backend fallan con no cipher suites in common. Quita las entradas TLS_RSA_* y configura los conjuntos de algoritmos de cifrado modernos compatibles con tu implementación de Java 21. Si no anulaste esta propiedad, los valores predeterminados de la versión 4.54.00 ya incluyen los conjuntos de cifrado compatibles y no es necesario realizar ningún cambio.
• Actualiza los algoritmos de cifrado internos del router al Message Processor: Si antes anulaste conf_message-processor-communication_local.http.ssl.ciphers con conjuntos de RSA estáticos, actualízalo con conjuntos de algoritmos de cifrado modernos compatibles con tu implementación de Java 21 antes de actualizar, o el router no podrá completar un protocolo de enlace TLS con el Message Processor. Luego, reinicia el procesador de mensajes:

  apigee-service edge-message-processor restart

  Consulta Configura TLS entre un Router y un Message Processor.

Para obtener detalles sobre cómo configurar TLS entre componentes de Edge, consulta Configura TLS entre un router y un Message Processor.

Herramienta de detección de cambios

Apigee proporciona una herramienta de detección de cambios para analizar tu clúster en busca de proxies de API, políticas, flujos compartidos y JAR de recursos implementados que puedan verse afectados por la actualización a Edge para nube privada 4.54.00.

La herramienta identifica posibles bloqueadores de actualización, incluidas las bibliotecas incompatibles con Java 21, las APIs internas con encapsulamiento estricto, las bajas de políticas heredadas y los límites de RDN de OpenLDAP, y produce informes prácticos para ayudarte a seleccionar las estrategias de solución adecuadas.

Para conocer todos los requisitos previos, las instrucciones de descarga, la sintaxis de la línea de comandos y los informes de muestra, consulta la guía de la herramienta de detección de cambios.