JBoss EAP 7 nativos são entregues de uma forma diferente neste lançamento. Agora alguns são enviados com o novo produto Red Hat JBoss Core Services, que é um grupo de softwares suplementares que é comum em muitos produtos middleware da Red Hat JBoss. O novo produto permite distribuição mais rápida de atualizações e uma experiência de atualização mais consistente. O produto JBoss Core Services está disponível para download em uma localidade diferente no Portal do Cliente Red Hat .

Várias mudanças foram feitas na Amazon Machine Images (AMI) no JBoss EAP 7. Esta seção resume brevemente algumas dessas mudanças.

Para detalhes sobre a implantação do JBoss EAP 7 no Amazon EC2, veja Implantando Red Hat JBoss Enterprise Application Platform na Amazon EC2.

Mudanças no servidor do JBoss EAP 7.1 e no plug-in do Maven podem resultar na seguinte falha quando você tentar desimplantar seu aplicativo. Esse erro pode ocorrer se seu aplicativo contiver módulos que interajam ou dependam um do outro.

WFLYCTL0184:    New missing/unsatisfied dependencies

Por exemplo, suponha que você tenha um aplicativo que contenha dois módulos de projeto do Maven WAR, application-A e application-B, que compartilham dados gerenciados pelo data-sharing módulo.

Ao implantar esse aplicativo, você deve implantar o compartilhamento data-sharing primeiro módulo e, em seguida, implemente os módulos que dependem dele. A ordem de implantação é especificada no <modules> elemento do pai pom.xml Arquivo. Isso é verdade nas versões 6.4 a 7.1 do JBoss EAP.

Nas versões anteriores do JBoss EAP, você poderia desimplantar todos os arquivos para este aplicativo a partir da raiz do projeto pai usando o seguinte comando.

$ mvn wildfly:undeploy

No JBoss EAP 7.1, você deve primeiro desimplantar os arquivos que usam os módulos compartilhados e, em seguida, remover os módulos compartilhados. Como não há como especificar a ordem de desocupação no projeto pom.xml arquivo, você deve desimplantar os módulos manualmente. Você pode fazer isso executando os seguintes comandos a partir da raiz do diretório pai.

$ mvn wildfly:undeploy -pl application-A,application-B
$ mvn wildfly:undeploy -pl data-shared

Esse novo comportamento de remoção de implementação é mais correto e garante que você não acabe em um estado de implantação instável.

o add-user O comportamento do script mudou no JBoss EAP 7 devido a uma mudança na política de senha. O JBoss EAP 6 tinha uma política de senha estrita. Como resultado, add-user O script rejeitou senhas fracas que não satisfaziam os requisitos mínimos. No JBoss EAP 7, senhas fracas são aceitas e um aviso é emitido. Para mais informações, veja Configurando Restrições de Senha do Utilitário Add-User no JBoss EAP Guia de configuração.

Quando o JBoss EAP 6.0 GA foi lançado pela primeira vez, o JBoss OSGi, uma implementação da especificação OSGi, foi incluído como um recurso de apresentação prévia de tecnologia. Com o lançamento do JBoss EAP 6.1.0, o JBoss OSGi foi rebaixado de apresentação técnica para não suportado.

No JBoss EAP 6.1.0, o configadmin e osgi módulos de extensão e configuração do subsistema para um servidor independente foram movidos para um EAP_HOME/standalone/configuration/standalone-osgi.xml arquivo de configuração. Como você não deve migrar esse arquivo de configuração não suportado, a remoção do suporte do JBoss OSGi não deve afetar a migração de uma configuração de servidor independente. Se você modificou qualquer um dos outros arquivos de configuração independentes para configurar osgi ou configadmin, essas configurações devem ser removidas.

Para um domínio gerenciado, o osgi extensão e configuração do subsistema foram removidos do EAP_HOME/domain/configuration/domain.xml arquivo na versão do JBoss EAP 6.1.0. No entanto, o configadmin a extensão do módulo e a configuração do subsistema permanecem no EAP_HOME/domain/configuration/domain.xml Arquivo. Esta configuração não é mais suportada no JBoss EAP 7 e deve ser removida.