Resolver falhas de implantação do AEM Cloud Manager causadas por erros de componentes OSGi personalizados

Este artigo descreve como solucionar problemas e resolver falhas de pipeline de implantação no Adobe Experience Manager (AEM) Cloud Manager quando os componentes OSGi personalizados não conseguem instanciar, resultando em ambientes instáveis e mensagens de log não claras.

Descrição description

Ambiente

Adobe Experience Manager (AEM) as a Cloud Service, implantado por meio de pipelines do Cloud Manager

Sintomas

  • Os pipelines de implantação falham e as novas implantações não atingem um estado estável.

  • As instâncias do aplicativo são reiniciadas com frequência e não ficam prontas.

  • Falha nas verificações de integridade, incluindo a Verificação de caminhos obrigatórios (Por exemplo: /libs/granite/security/currentuser.json retorna HTTP 503) e a Verificação de componentes obrigatórios (personalizada) relata componentes não atendidos.

  • Os registros mostram componentes OSGi personalizados que não são instanciados, com erros como:

    • javax.jcr.nodetype.NosuchNodeTypeException: cliente de tipo de nó não existe
    • Construtor com 0 argumentos não encontrado para autenticação personalizada ou componentes inicializadores de repositório

Causa

Os componentes OSGi personalizados não são instanciados devido a descritores de componentes incompatíveis, tipos de nó JCR ausentes ou configurações de fábrica incorretas. Isso resulta em falhas de serviços essenciais e impede uma implantação bem-sucedida.

Resolução resolution

Siga as etapas abaixo para resolver o problema:

  1. Revise o código para componentes OSGi personalizados, como inicializadores de repositório e pacotes de autenticação.

  2. Verifique se todos os tipos de nó JCR referenciados (por exemplo: cliente) existem antes que qualquer lógica de criação de pasta seja executada no código personalizado.

  3. Verifique os descritores do componente OSGi para verificar se eles correspondem às assinaturas do construtor nas classes compiladas.

  4. Confirme se as configurações de fábrica para componentes de autenticação personalizados (como ProviderConfigImpl, ProviderConfigServiceManagerImpl, OAuthManagerImpl) estão corretas e não foram introduzidas ou modificadas recentemente na implantação mais recente.

  5. Valide a configuração de verificação de integridade:

    • Localize a configuração OSGi para a verificação de integridade Componentes Obrigatórios (personalizados) (geralmente uma configuração de fábrica para org.apache.felix.hc.generalchecks.ComponentsCheck, marcada como personalizada).

    • Confirme se a lista de componentes obrigatórios inclui os componentes personalizados afetados.

    • Usar a Interface para toque do AEM (Ferramentas > Operações > Verificação de integridade) para revisar o status atual e as mensagens para a verificação de integridade personalizada.

  6. Depois de corrigir os problemas identificados, reimplante os pacotes afetados e verifique se o ambiente atinge um estado estável de preparação e se todas as verificações de integridade foram bem-sucedidas.

recommendation-more-help
experience-cloud-kcs-help-kbarticles