O Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP) é uma plataforma de middleware construída em padrões abertos e compatível com a especificação Java Enterprise Edition 7. Ele integra o WildFly Application Server 10 com um sistema de mensagens, clusterização de alta disponibilidade e outras tecnologias.

O JBoss EAP oferece uma estrutura modular que permite a habilitação de serviços apenas quando necessário, melhorando a velocidade da inicialização.

O Console de Gerenciamento e a CLI (Interface de Linha de Comando) de Gerenciamento tornam as edições dos arquivos de configuração XML desnecessárias e agregam a habilidade de utilizar script e automatizar tarefas.

O JBoss EAP fornece dois modos de operação para as instâncias do JBoss EAP: o servidor autônomo ou o domínio gerenciado. O modo de operação do servidor autônomo representa o JBoss EAP em execução como uma instância de servidor único. O modo de operação do domínio gerenciado permite o gerenciamento de múltiplas instâncias do JBoss EAP a partir de um ponto de controle único.

Além disso, o JBoss EAP inclui APIs e estruturas para o desenvolvimento rápido de aplicativos Java EE seguros e escaláveis.

The purpose of this guide is to document the changes that are required to successfully run and deploy Red Hat JBoss Enterprise Application Platform 6 applications on Red Hat JBoss Enterprise Application Platform 7. It provides information about the new features available in this release, the deprecated and unsupported features, and any application and server configuration updates that might be required to prevent changes in application behavior.

Também fornece informação sobre ferramentas que podem ajudá-lo com a migração, como Windup, que simplifica a migração de aplicativos Java e JBoss Server Migration Tool, que atualiza a configuração do servidor.

Uma vez que o aplicativo foi implementado com êxito e esta sendo executado, pode-se fazer planos para atualizar componentes individuais para utilizar as novas funções e recursos de JBoss EAP 7.

Se você planeja migrar seus aplicativos JBoss EAP 5 diretamente para JBoss EAP 7, consulte Migrating from Older Releases of JBoss EAP.

Neste documento, a variável EAP_HOME é usada para denotar o caminho para a instalação do JBoss EAP. Substitua esta variável pelo caminho atual da sua instalação do JBoss EAP 7.

In JBoss EAP 7, an effort was made to provide backward compatibility for JBoss EAP 6 applications. However, if your application uses features that were deprecated or functionality that was removed from JBoss EAP 7, you might need to make changes to your application code.

In addition, a number of things have changed in this release that might impact deployment of JBoss EAP 7 applications. It is recommended that you do some research and planning before you attempt to migrate your application.

Depois que você se familiarizar com as alterações dos recursos, com os materiais de desenvolvimento e as ferramentas que podem auxiliar os seus eforços de migração, você pode começar a avaliar os seus aplicativos e a configuração do seu servidor para determinar as alterações necessárias para a execução do JBoss EAP 7.

O Java EE 7 inclui diversas melhorias para facilitar o desenvolvimento e a execução dos aplicativos com muitos recursos em nuvens públicas e privadas. Ele incorpora novos recursos e os padrões mais recentes, como HTML5, WebSocket, JSON, Batch e Concurrency Utilities. As atualizações incluem JPA 2.1, JAX-RS 2.0, Servlet 3.1, Expression Language 3.0, JMS 2.0. JSF 2.2, EJB 3.2, CDI 1.2 e Bean Validation 1.1.

Você pode encontrar mais informações sobre o Java EE 7, incluindo tutoriais, no site do Oracle: Java EE at a Glance

O JBoss EAP 7 inclui algumas melhorias e upgrades importantes com relação ao último lançamento.

For a complete list of new features, see New Features and Enhancements in the JBoss EAP 7 Release Notes.

Before you migrate your application, be aware that some features that were available in previous releases of JBoss EAP might be deprecated or no longer supported.

O suporte para algumas tecnologias foi removido devido ao alto custo de manutenção, pouco interesse da comunidade e soluções alternativas muito melhores. O que segue é um breve resumo de alguns dos recursos sem suporte.

For a comprehensive list of deprecated and unsupported features, see Unsupported and Deprecated Functionality in the JBoss EAP 7 Release Notes.

Be sure to review the JBoss EAP Getting Started Guide. It contains the following important information:

Each application and server configuration is unique and you must thoroughly understand the components and architecture of the existing application and server platform before you attempt the migration. Your migration plan should include a detailed roadmap for testing and roll out to production that takes into account the following information.

Antes de migrar seu aplicativo, você precisa estar ciente dos possíveis problemas:

Certifique-se também de fazer o backup das configurações do servidor atual e aplicativos antes de começar.

To install JBoss EAP 7 using RPMs, see the JBoss EAP Installation Guide.

The migration advice in this guide also applies to migrating RPM installations of JBoss EAP, but you might need to alter some steps (such as how to start JBoss EAP) to suit an RPM installation compared to a ZIP or installer installation.

If you run JBoss EAP 6 as a service, be sure to review Configuring JBoss EAP to Run as a Service in the JBoss EAP Installation Guide for updated configuration instructions for JBoss EAP 7.

O Windup, que faz parte do conjunto de ferramentas de migração do Red Hat JBoss, é uma ferramenta extensível e personalizável baseada em regras que auxiliam simplificar a migração de aplicativos Java. Esta ferramenta analisa APIs, tecnologias e arquiteturas utilizadas pelos aplicativos que você planeja migrar e fornece relatórios detalhados de migração para cada aplicativo. Estes relatórios fornecem as seguintes informações:

Você pode utilizar Windup para analisar o código e arquitetura do seus aplicativos JBoss EAP 6 antes de migrá-los para o JBoss EAP 7. O conjunto de regras do Windup para migração do JBoss EAP 6 para o JBoss EAP 7 relata em descritores XML e códigos de aplicativos específicos e parâmetros que precisam ser substituídos por uma configuração alternativa quando migrar para o JBoss EAP 7.

Para mais informações sobre como usar Windup para analisar seu JBoss EAP 6 applications, consulte o Windup User Guide.

A ferramenta de migração de servidor JBoss, que está atualmente em desenvolvimento, será o método preferido para atualizar sua configuração para incluir os novos recursos e configurações no JBoss EAP 7 enquanto mantém sua configuração existente.

A ferramenta de migração de servidor JBoss lê seu arquivo de configuração de servidor JBoss EAP 6 existente e adiciona configurações para os novos subsistemas, atualiza configurações de subsistemas existentes com novos recursos e remove configurações de subsistemas obsoletas.

O mais recente pré-lançamento de distribuição binária do JBoss Server Migration Tool está disponível para download em https://github.com/wildfly/wildfly-server-migration/releases. Esta versão suporta migração de servidores autônomos do JBoss EAP 6.4 para JBoss EAP 7.0. Para informações gerais sobre como executar a ferramenta, consulte o Guia do Usuário do JBoss Server Migration Tool.

Para migrar sua configuração de servidor do JBoss EAP 6 para JBoss EAP 7, você pode utilizar a ferramenta de migração do servidor JBoss ou fazer uma migração manual com o auxílio da operação migrate da CLI de gerenciamento.

Ferramenta de migração de servidor JBoss

A ferramenta de migração de servidor JBoss, que está atualmente em desenvolvimento, será o método preferido para atualizar sua configuração para incluir os novos recursos e configurações no JBoss EAP 7 enquanto mantém sua configuração existente.

Operação de migração da CLI de gerenciamento

Você pode utilizar a operação migrate da CLI de gerenciamento para atualizar os subsistemas jacorb, messaging e web no arquivo de configuração do servidor JBoss EAP 6 para permitir que executem na nova versão, mas esteja ciente de que o resultado não é uma configuração completa JBoss EAP 7. Por exemplo:

Para mais informação sobre como utilizar a operação migrate para migração da configuração do servidor, consulte Operação de migração da CLI de gerenciamento.

Você pode utilizar a CLI de gerenciamento para atualizar seus arquivos de configurações do servidor JBoss EAP 6 para executar em JBoss EAP 7. A CLI de gerenciamento fornece uma operação de migração para atualizar automaticamente os subsistemas jacorb, messaginge web da versão anterior para a nova configuração. Você pode também executar a operação describe-migration para os subsistemas jacorb, messagingeweb para revisar as mudanças de configuração de migração propostas, antes que você execute a migração. Não há substitutos para os subsistemas cmp, jaxr outhreads e eles devem ser removidos das configurações do servidor.

Inicie o servidor e a CLI de gerenciamento

Siga as etapas abaixo para atualizar sua configuração do servidor JBoss EAP 6 para executar em JBoss EAP 7.

Migrar JacORB, Messaging e subsistemas Web

Os registros de mensagens são prefixados com o código do projeto para o subsistema que relata a mensagem. Os prefixos para todos os registros de mensagens foram alterados no JBoss EAP 7.

For a complete list of the new log message project code prefixes used in JBoss EAP 7, see Project Codes Used in JBoss EAP in the JBoss EAP Development Guide.

If you use the management CLI migrate operation to upgrade your existing configuration, you might see exceptions in the server log when you deploy your EJB applications.

DuplicateServiceException

A seguinte DuplicateServiceException é causada ao fazer a memorização das alterações em JBoss EAP 7.

ERRO [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Falha ao iniciar serviço jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException no serviço  jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Falha ao iniciar serviço
...
Causado por: org.jboss.msc.service.DuplicateServiceException: Serviço jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config já esta registrado

Você deve reconfigurar o cache para resolver este erro.

No JBoss EAP 7, Active MQ Artemis substitui HornetQ como o fornecedor de suporte JMS. Esta seção descreve como migrar a configuração e dados de mensagens relacionados.

/subsystem=messaging:migrate

/subsystem=messaging:describe-migration

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

java -jar -mp MODULE_PATH org.hornetq.exporter MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

/subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

The HornetQ component in JBoss EAP 6 provided its own JMX management; however, it was not recommended and is now deprecated and no longer supported. If you relied on this feature in JBoss EAP 6, you must migrate your management tooling to use either the JBoss EAP management CLI or the JMX management provided with JBoss EAP 7.

You must also upgrade your client libraries to use the jboss-client.jar that ships with JBoss EAP 7.

The following is an example of HornetQ JMX management code that was used in JBoss EAP 6.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // HornetQ used the protocol "remoting-jmx" and port "9999"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remoting-jmx://127.0.0.1:9999");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name pointed to the HornetQ JMX management
    ObjectName objectName = new ObjectName("org.hornetq:type=Server,module=JMS");

    // The invoked method name was "listConnectionIDs"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIDs", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

The following is an example of the equivalent code needed for ActiveMQ Artemis in JBoss EAP 7.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // ActiveMQ Artemis uses the protocol "remote+http" and port "9990"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name points to the new JMX management in the `messaging-activemq` subsystem
    ObjectName objectName = new ObjectName("jboss.as:subsystem=messaging-activemq,server=default");

    // The invoked method name is now "listConnectionIds"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIds", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

Notice that the method names and parameters have changed in the new implementation. You can find the new method names in the JConsole by following these steps.

A implementação do JacORB foi substituída com uma ramificação downstream do OpenJDK ORB no JBoss EAP 7.

O módulo de extensão org.jboss.as.jacorb, localizado em EAP_HOME/modules/system/layers/base/, foi substituído pelo módulo de extensão org.wildfly.iiop-openjdk.

O espaço de nomes da configuração do subsistema urn:jboss:domain:jacorb:1.4 no arquivo de configuração do servidor foi substituído pelo espaço de nome urn:jboss:domain:iiop-openjdk:1.0.

Segue um exemplo de configuração de sistema padrão jacorb em JBoss EAP 6.

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
        <initializers security="identity" transactions="spec"/>
    </orb>
</subsystem>

Segue um exemplo de configuração de subsistema iiop-openjdk padrão no JBoss EAP 7.

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl" />
    <initializers security="identity" transactions="spec" />
</subsystem>

A nova configuração de subsistema iiop-openjdk aceita somente um subconjunto de elementos legados e atributos. Segue um exemplo de configuração de subsistema jacorb na versão prévia do JBoss EAP que contém todos os elementos válidos e atributos:

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
   <orb name="JBoss" print-version="off" use-imr="off" use-bom="off"  cache-typecodes="off"
       cache-poa-names="off" giop-minor-version="2" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
       <connection retries="5" retry-interval="500" client-timeout="0" server-timeout="0"
           max-server-connections="500" max-managed-buf-size="24" outbuf-size="2048"
           outbuf-cache-timeout="-1"/>
       <initializers security="off" transactions="spec"/>
   </orb>
   <poa monitoring="off" queue-wait="on" queue-min="10" queue-max="100">
       <request-processors pool-size="10" max-threads="32"/>
   </poa>
   <naming root-context="JBoss/Naming/root" export-corbaloc="on"/>
   <interop sun="on" comet="off" iona="off" chunk-custom-rmi-valuetypes="on"
       lax-boolean-encoding="off" indirection-encoding-disable="off" strict-check-on-tc-creation="off"/>
   <security support-ssl="off" add-component-via-interceptor="on" client-supports="MutualAuth"
       client-requires="None" server-supports="MutualAuth" server-requires="None"/>
   <properties>
       <property name="some_property" value="some_value"/>
   </properties>
</subsystem>

Os seguintes atributos de elementos não possuem mais suporte e devem ser removidos.

Os seguintes atributos on/off não possuem mais suporte e não serão migrados quando você executar a operação migrate da CLI de gerenciamento. Se eles estão definidos como on, você irá receber um alerta de migração. Outros atributos on/off que não foram mencionados nesta tabela, por exemplo, <security support-ssl="on|off">, ainda possuem suporte e serão migrados com êxito. A única diferença é que os valores serão alterados de on/off para true/false.

A configuração de servidor do JBoss EAP 6 incluía um subsistema threads que era utilizado para gerenciar grupos de thread em vários subsistemas no servidor.

O subsistema threads não está mais disponível no JBoss EAP 7. Como alternativa, cada subsistema é responsável por gerenciar seus próprios grupos de thread.

For information about how to configure thread pools for the infinispan subsystem, see Configure Infinispan Thread Pools in the JBoss EAP Configuration Guide.

For information about how to configure thread pools for the jgroups subsystem, see Configure JGroups Thread Pools in the JBoss EAP Configuration Guide.

In JBoss EAP 6, you configured thread pools for connectors and listeners for the web subsystem by referencing an executor that was defined in the threads subsystem. In JBoss EAP 7, you now configure thread pools for the undertow subsystem by referencing a worker that is defined in the io subsystem. For more information, see Configuring the IO Subsystem in the JBoss EAP Configuration Guide.

For information about about changes to thread pool configuration in the remoting subsystem, see Migrate the Remoting Subsystem Configuration in this guide, and Configuring the Endpoint in the JBoss EAP Configuration Guide.

No JBoss EAP 6, você configura o agrupamento de thread para o subsistema remoting ao determinar vários atributos worker-*. O agrupamento de thread de worker não é mais configurado no subsistema remoting no JBoss EAP 7 e caso você tentar modificar a configuração existente, você virá a seguinte mensagem.

WFLYRMT0022: Configuração worker não é mais utilizada, por favor, use configuração endpoint worker

No JBoss EAP 7, o worker thread pool é substituído por uma configuração de ponto de extremidade que referencia um subsistema worker definido no subsistema io.

For information about how to configure the endpoint, see Configuring the Endpoint in the JBoss EAP Configuration Guide.

Para utilizar WebSockets no JBoss EAP 6, você tinha que habilitar o protocolo conector Java NIO2 não bloqueante para conector http no subsistemaweb do arquivo de configuração do servidor JBoss EAP utilizando o comando similar ao que segue.

/subsystem=web/connector=http/:write-attribute(name=protocol,value=org.apache.coyote.http11.Http11NioProtocol)

Para utilizar WebSockets em um aplicativo, você tinha também que criar um elemento <enable-websockets> no arquivo WEB-INF/jboss-web.xml do aplicativo e defini-lo para true.

No JBoss EAP 7, você não precisa mais configurar o servidor para suporte WebSocket padrão ou configurar o aplicativo para utilizá-lo. WebSockets são exigências da especificação do Java EE 7 e os protocolos exigidos são configurados por padrão. Configurações de WebSocket mais complexas são feitas no servlet-container do subsistema undertow do arquivo de configuração do servidor JBoss EAP. Você pode ver as configurações disponíveis utilizando o seguinte comando.

/subsystem=undertow/servlet-container=default/setting=websockets:read-resource(recursive=true)
{
   "outcome" => "success",
   "result" => {
       "buffer-pool" => "default",
       "dispatch-to-worker" => true,
       "worker" => "default"
   }
}

Exemplos de códigos WebSocket também podem ser encontrados no início rápido (quickstarts) que é fornecido com JBoss EAP.

The infinispan subsystem still provides distributed caching support for HA services in the form of Infinispan caches in JBoss EAP 7; however the caching and distribution of authentication information is handled differently than in previous releases.

No JBoss EAP 6, se o single sign-on (SSO) não foi fornecido um cache Infinispan, o cache não era distribuído.

No JBoss EAP 7, SSO é distribuído automaticamente quando você seleciona o perfil HA. Quando executar com o perfil HA, cada host tem seu próprio cache Infinispan, que é baseado no cache padrão do contêiner de cache da web. Este cache armazena sessões relevantes e informações de cookie SSO para o host. JBoss EAP trata a propagação de informação de cache individual para todos os hosts. Não existe nenhuma maneira para atribuir especificamente um cache Infinispan para um SSO no JBoss EAP 7.

No JBoss EAP 7, o SSO é configurado no subsistema undertowdo arquivo de configuração do servidor.

Não há exigência de alteração de código de aplicativos para SSO quando migrando para JBoss EAP 7.

For information about Java Security Manager server configuration changes, see Considerations Moving from Previous Versions in How To Configure Server Security for JBoss EAP.

Alguns atributos de configuração do gerenciamento de transações que estavam disponíveis no subsistema transactions no JBoss EAP 6 foram alterados no JBoss EAP 7.

Removed Transactions Subsystem Attributes

A seguinte tabela lista os atributos do JBoss EAP 6 que foram removidos do subsistema transactions no JBoss EAP 7 e os atributos substituídos correspondentes.

Atributos de subsistema de transações preteridos

The following attributes that were available in the transactions subsystem in JBoss EAP 6 are deprecated in JBoss EAP 7. The deprecated attributes might be removed in a future release of the product. The following table lists the equivalent replacement attributes.

A configuração para listas de proxy estáticas em mod_cluster foi alterada no JBoss EAP 7.

No JBoss EAP 6, você configurava o atributo proxy-list, que era um lista separada por vírgula de endereços proxy httpd especificados no formato de hostname:port.

O atributo proxy-list é preterido no JBoss EAP 7. Ele foi substituído pelo atributo proxies, que é uma lista de nomes de associação de soquetes de saída.

This change impacts how you define a static proxy list, for example, when disabling advertising for mod_cluster. For information about how to disable advertising for mod_cluster, see Disable Advertising for mod_cluster in the JBoss EAP Configuration Guide.

For more information about mod_cluster attributes, see ModCluster Subsystem Attributes in the JBoss EAP Configuration Guide.

JBossWS 5 traz novos recursos e melhorias de desempenho para servidores web JBoss EAP 7, principalmente através de atualizações de componentes Apache CXF, Apache WSS4J e Apache Santuario .

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

No JBoss EAP 7, o conector padrão foi alterado de remoto para http-remoting e a porta de conexão remota padrão foi alterada de 4447 para 8080. O URL do fornecedor JNDI para a configuração padrão foi alterado de remote://localhost:4447 para http-remoting://localhost:8080.

If you use the JBoss EAP 7 migrate operation to update your configuration, you do not need to modify the remote connector, remote port, or JNDI provider URLs because the migration operation preserves the JBoss EAP 6 remoting connector and 4447 port configuration settings in the subsystem configuration. For more information about the migrate operation, see Management CLI Migration Operation.

Se você não usar a operação migrate e em vez disso executar com a configuração padrão nova do JBoss EAP 7, você deve alterar o conector remoto, porta remota e URL do fornecedor JNDI para usar as novas definições conforme descrito acima.

Os lançamentos prévios do JBoss EAP agrupava RESTEasy 2, que era uma implementação do JAX-RS 1.x. O JBoss EAP 7 inclui RESTEasy 3, que é uma implementação do JAX-RS 2.0 conforme definido pelo JSR 339: JAX-RS 2.0: A API Java para especificações RESTful Web Services. Para mais informações sobre API Java para RESTful Web Services, consulte a Especificação de API JAX-RS 2.0.

A versão de Jackson incluída no JBoss EAP foi alterada. A versão anterior do JBoss EAP incluía Jackson 1.9.9. O JBoss EAP 7 inclui agora Jackson 2.6.3 ou superior.

This section describes how these changes might impact applications that use RESTEasy or JAX-RS.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

JBoss EAP 7 includes support for CDI 1.2. As a result, applications written using CDI 1.0 might see some changes in behavior when migrated to JBoss EAP 7. This section summarizes only a few of those changes.

Você pode encontrar mais informações sobre Weld e CDI 1.2 nas seguintes referências:

Arquivos Bean

As classes Bean de beans ativos devem ser implantadas nos arquivos bean para certificarmos de que estão escaneados pelo CDI para achar e processar as classes bean.

Em CDI 1.0, um arquivo era definido como um arquivo bean explicit se contivesse um arquivo beans.xml no diretório META-INF/ para um aplicativo cliente, EJB ou biblioteca JAR; ou se contivesse um arquivo beans.xml no diretório WEB-INF/ para um WAR.

CDI 1.1 introduziu arquivos bean implicit, que são arquivos que contêm uma ou mais classes de bean com uma anotação de definição de bean, ou uma ou mais sessões beans. Arquivos beans implícitos são escaneados por CDI e, durante o descobrimento do tipo, somente classes com anotações de definição bean são descobertas. Para mais informações, consulte Descoberta de Bean e tipo em Injeção de dependências e contextos para plataforma Java EE.

Um arquivo bean possui modos de descobertas de bean all, annotated ou none. Um arquivo bean que contém um arquivo beans.xml sem versão tem um modo de descoberta de bean padrão all. Um arquivo bean que contém um arquivo beans.xml com versão 1.1 ou mais recente deve especificar o atributo bean-discovery-mode. O valor padrão para o atributo é annotated.

Um arquivo não é um arquivo bean nos seguintes casos:

Um arquivo é um arquivo bean explicit nos seguintes casos:

Um arquivo é um arquivo bean implicit nos seguintes casos:

CDI 1.2 limitava anotações de definição de bean para o seguinte:

Para mais informações sobre os arquivos bean, consulte Arquivos Bean em Contextos e injeções de dependências para a plataforma Java EE .

Esclarecimento de resolução de conversação

O ciclo de vida de contexto de conversação foi alterado para prevenir conflitos com as especificações do Servlet conforme descrito em Problema de especificação CDI-411. O escopo de conversação está ativo durante todas as requisições servlet e não deve impedir que outros servlets ou filtros de servlet definam o corpo da requisição ou codificação do caractere.

Resolução por observação

A resolução de evento foi parcialmente reescrita em CDI 1.2. Em CDI 1.0, um evento é entregue a um método de observação se o método de observação possui todos os qualificadores de evento. Em CDI 1.2, um evento é entregue a um método de observação se o método de observação não possui qualificadores de evento ou possui um subconjunto dos qualificadores de evento.

A introdução de sistema de carregamento de classe modular e JBoss Modules nos lançamentos prévios do JBoss EAP permitiam controle de alta granularidade das classes disponíveis para aplicativos. Este recurso permitia que você configurasse dependências de módulo explícito usando o arquivo MANIFEST.MF do aplicativo ou o arquivo descritor de implantação jboss-deployment-structure.xml.

Se você definiu dependências de módulo explícito em seu aplicativo, você deve estar ciente das seguintes alterações no JBoss EAP 7.

Verifique dependências para disponibilidade

Os módulos que estão incluídos no JBoss EAP foram alterados. Quando você migrar seu aplicativo para JBoss EAP 7, verifique suas entradas de arquivo MANIFEST.MF e jboss-deployment-structure.xml para certificar-se de que elas não se referem a nenhum módulo que foi removido neste lançamento de produto.

Dependências que requerem scan de anotação

No lançamento prévio do JBoss EAP, caso sua dependência contivesse anotações que precisavam ser processadas durante o scan de anotação, por exemplo quando declarando interceptadores EJB, era solicitado que você gerasse e incluísse um índice Jandex em um novo arquivo JAR e depois definisse um sinalizador no arquivo descritor de implantação MANIFEST.MF ou jboss-deployment-structure.xml.

Agora JBoss EAP 7 oferece geração de tempo de execução automática de índices de anotação para módulos estáticos, assim você não precisa mais gerá-los manualmente. Contudo, você ainda precisa adicionar o sinalizador annotations ao arquivo MANIFEST.MF do aplicativo ou o arquivo descritor de implantação jboss-deployment-structure.xml conforme demonstrado abaixo.

Dependências: com.company.my-ejb annotations, com.company.other

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.company.my-ejb" annotations="true"/>
      <module name="com.company.other"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

A versão do Hibernate Search fornecida com JBoss EAP 7 foi alterada. O lançamento prévio do JBoss EAP fornecia Hibernate Search 4.6.x. O JBoss EAP 7 fornece Hibernate Search 5.5.x.

Hibernate Search 5.5 is built upon Apache Lucene 5.3.1. If you use any native Lucene APIs, be sure to align with this version. The Hibernate Search 5.5 API wraps and hides the complexity of many of the Lucene API changes made between version 3 and version 5, however, some classes are now deprecated, renamed, or repackaged. This section describes how these changes might impact your application code.

Alterações de mapeamento do Hibernate Search

Indexing of id Fields of Embedded Relations

Quando usar uma anotação @IndexedEmbedded para incluir campos de uma entidade relacionada, a id da entidade relacionada não é mais incluída. Você pode ativar a inclusão da id ao usar o atributo includeEmbeddedObjectId da anotação @IndexedEmbedded.

@IndexedEmbedded(includeEmbeddedObjectId=true)

Modificações na formatação do índice de data e número

Agora, números e datas são indexados por padrão como campos numéricos. Propriedades de tipo int, long, float, double, e suas classes encapsuladas correspondentes não são mais indexadas como cadeias. Ao invés, elas são agora indexadas usando codificação Lucene numérica apropriada. Os campos id são é uma exceção a esta regra. Mesmo quando são representados por um tipo numérico, eles ainda são indexados como uma palavra-chave de cadeia por padrão. Agora, o uso de @NumericField é preterido, a não ser que você queira especificar uma precisão personalizada para a codificação numérica. Você pode manter o antigo formato de índice baseado em cadeia ao especificar explicitamente uma ponde de campo de codificação em cadeia. No caso de inteiros, isto é o org.hibernate.search.bridge.builtin.IntegerBridge. Verifique o pacote org.hibernate.search.bridge.builtin para outras pontes de campos acessíveis publicamente.

Data e Calendário não são mais indexados como cadeias. Ao invésdisso, instâncias são codificadas como valores compridos representando o número de milissegundos desde 1 de janeiro de 1970, 00:00:00 GMT. Você pode trocar o formato de indexação ao usar EncodingType enum. Por exemplo:

@DateBridge(encoding=EncodingType.STRING)
@CalendarBridge(encoding=EncodingType.STRING)

A alteração de codificação para números e datas é importante e pode ter um grande impacto no comportamento do aplicativo. Se você tem uma consulta que se destina a um campo que foi previamente codificado em cadeia, mas está agora codificado numericamente, você deve atualizar esta consulta. Campos numéricos devem ser pesquisados com um NumericRangeQuery. Você deve também certificar-se que todos os campos destinados por facetamento são codificados em cadeia. Se você usar a consulta DSL Search, a consulta correta deve ser criada automaticamente para você .

Alterações diversas no Hibernate Search

Classes de Hibernate Search renomeadas e reempacotadas

A lista que segue é uma lista de classes de Hibernate Search que foram reempacotadas ou renomeadas.

Lucene - Classes renomeadase reempacotadas

Os analisadores de consultas foram movidos para um novo módulo, resultando em uma alteração de pacotes de org.apache.lucene.queryParser.QueryParser para org.apache.lucene.queryparser.classic.QueryParser.

Vários analisadores Lucene foram refatorados resultando em alterações de pacotes. Consulte Documentação Apache Lucene para procurar pacotes substitutos.

Algumas classes de utilidades Apache Solr, por exemplo TokenizerFactory ou TokenFilterFactory, foram movidas para o Apache Lucene. Caso seu aplicativo usar estas utilidades ou analisadores personalizados, você deve procurar o novo nome de pacote no Apache Lucene.

Consulte o Guia de Migração Apache Lucene para mais informações.

APIs Hibernate Search preteridas

Para a lista completa de interfaces preteridas de Hibernate Search, de classes, de enums, tipos de anotações, métodos, construtores e constantes de enum, consulte o documento Hibernate Search Deprecated API.

Interfaces preteridas de Hibernate Search

Classes Hibernate Search preteridas

Hibernate Search Deprecated Enums

Anotações preteridas de Hibernate Search

Métodos preteridos de Hibernate Search

Construtores preteridos de Hibernate Search

Alterações que impactam integradores avançados

Esta seção descreve alterações que não fazem parte da API pública. Isto não deve impactar o desenvolvedor comum pois estes artefatos devem ser acessados somente por integradores que estendem a framework Hibernate Search.

Suporte para beans de entidade EJB é facultativo em Java EE 7 e não são suportados em JBoss EAP 7. Isto significa que beans de entidade de persistência gerenciada por contêiner (CMP) e persistência gerenciada pelo bean (BMP) devem ser reescritos para usar entidades Java Persistence API (JPA) quando você migrar para JBoss EAP 7.

Nas versões anteriores de JBoss EAP, beans de entidade eram criados em código fonte de aplicativo ao estender a classe javax.ejb.EntityBean e implementar os métodos requeridos. A partir dai, eles eram configurados no arquivo ejb-jar.xml. Um bean de entidade CMP era especificado usando um elemento <entity> que continha um elemento filho <persistence-type> com um valor de Container. Um bean de entidade BMP era especificado usando um elemento <entity> que continha um elemento filho <persistence-type> com um valor de Bean.

EmJBoss EAP 7, você deve substituir quaisquer beans de entidade CMP e BMP em seu código com entidades Java Persistence API (JPA). Entidades JPA são criadas usando as classesjavax.persistence.* e são definidas no arquivo persistence.xml.

O que segue é um exemplo de uma classe de entidade JPA.

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
// User is a keyword in some SQL dialects!
@Table(name = "MyUsers")
public class MyUser {
    @Id
    @GeneratedValue
    private Long id;

    @Column(unique = true)
    private String username;
    private String firstName;
    private String lastName;

    public Long getId() {
        return id;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

O seguinte é um exemplo de um arquivo persistence.xml.

<persistence version="2.1"
      xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="my-unique-persistence-unit-name">
    <properties>
      // properties...
    </properties>
  </persistence-unit>
</persistence>

Para obter exemplos de entidades JPA, consulte o início rápido bmt, cmt e hibernate5 que fornecido em JBoss EAP 7.

Uma nova propriedade de persistência, jboss.as.jpa.deferdetach, foi adicionada para fornecer compatibilidade com o comportamento de persistência em lançamentos prévios de JBoss EAP.

A propriedade jboss.as.jpa.deferdetach controla se o contexto de persistência transaction-scoped utilizado em uma thread de transação non-JTA desanexa entidades carregadas após cada invocação EntityManager ou se aguarda até que o contexto de persistência esteja fechado, por exemplo, quando é finalizada a sessão de invocação de bean. O valor de propriedade é por padrão false, o que significa que entidades são desanexadas ou removidas após cada invocação EntityManager. Este é o comportamento padrão correto conforme definido em especificação JPA . Caso o valor de propriedade estiver definido para true, as entidade não são desanexadas até que o contexto de persistência esteja fechado.

Em JBoss EAP 5, as persistências comportavam-se como se a propriedade jboss.as.jpa.deferdetach estivesse definida para true. Para obter este mesmo comportamento quando migrar seu aplicativo do JBoss EAP 5 para JBoss EAP 7, você deve definir o valor de propriedade jboss.as.jpa.deferdetach para true em seu persistence.xml conforme explicado no seguinte exemplo.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="EAP5_COMPAT_PU">
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
    <properties>
         <property name="jboss.as.jpa.deferdetach" value="true" />
    </properties>
  </persistence-unit>
</persistence>

Em JBoss EAP 6, as persistências comportavam-se como se a propriedade jboss.as.jpa.deferdetach estivesse definida para falso. Este é o mesmo comportamento encontrado em JBoss EAP 7, por isso não há necessidades de alterações quando você migrar seu aplicativo.

O conector remoto padrão e porta foram alterados no JBoss EAP 7. Para detalhes sobre esta mudança, consulte Atualize o conector URL remoto e porta.

Se você usou a operação migrate para migrar sua configuração de servidor, as definições antigas são preservadas e você não precisa fazer as alterações detalhadas abaixo. Contudo, se você executa com a nova configuração padrão de JBoss EAP 7, você deve fazer as seguintes alterações.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

A especificação Java EE Application Deployment (JSR-88) destinava-se a definir um contrato padrão para permitir que ferramentas de vários provedores configurassem e implantarem aplicativos em qualquer produto de plataforma Java EE. O contrato exigia que os provedores de produtos Java EE implementassem as interfaces DeploymentManager e outras interfaces javax.enterprise.deploy.spi para serem acessadas pelos provedores de ferramentas. No caso do JBoss EAP 6, um plano de implementação é identificado por um descritor XML denominado deployment-plan.xml que está incluído em um arquivo ZIP ou JAR.

Esta especificação teve pouca aceitação pois a maioria dos produtos de servidores de aplicativos fornecem suas próprias soluções de implementação mais "ricas em recursos ". Por esta razão, o suporte JSR-88 foi abandonado a partir do Java EE 7, por sua vez, abandonado a partir do JBoss EAP 7.

If you used JSR-88 to deploy your application, you must now use another method to deploy the application. The JBoss EAP management CLI deploy command provides a standard way to deploy archives to standalone servers or to server groups in a managed domain. For more information about the management CLI, see the Management CLI Guide.

Você deve migrar manualmente válvulas personalizadas ou qualquer válvulas que estão definidas no arquivo XMLjboss-web.xml. Isto inclui válvulas criadas ao estender as classes org.apache.catalina.valves.ValveBase e configuradas no elemento <valve> do arquivo descritor jboss-web.xml.

Migrar válvulas configuradas em implementações

No JBoss EAP 6, você podia definir válvulas personalizadas ao nível de aplicativo ao configurá-las no arquivo descritor de aplicativo web jboss-web.xml. No JBoss EAP 7, é possível fazer isto também com os manipuladores Undertow.

O que segue é um exemplo de uma válvula configurada no arquivo jboss-web.xml no JBoss EAP 6.

<jboss-web>
    <valve>
        <class-name>org.jboss.examples.MyValve</class-name>
​        <param>
    ​        <param-name>myParam</param-name>
​            <param-value>foobar</param-value>
    ​    </param>
    </valve>
</jboss-web>

For more information about how to create and configure custom handlers in JBoss EAP, see Creating Custom Handlers in the JBoss EAP Development Guide.

Migrar válvulas de autenticador personalizadas

Para informação sobre como migrar válvulas de autenticador, consulte Alterações de aplicativos de segurança

A substituição de JBoss Web com Undertow requer alterações nas configurações de segurança no JBoss EAP 7.

Se seu aplicativo usa JBoss Logging, esteja ciente de que as anotações no pacote org.jboss.logging agora são preteridas no JBoss EAP 7. Elas foram movidas para o pacote org.jboss.logging.annotations, então você deve atualizar seu código-fonte para importar o novo pacote.

As anotações também foram movidas para um ID de Maven groupId:artifactId:version (GAV) separado, assim você precisa adicionar uma nova dependência de projeto para org.jboss.logging:jboss-logging-annotations em seu arquivo de projeto pom.xml.

A tabela seguinte lista as classes de anotações preteridas e substituições correspondentes.

Suporte para JSF 1.2 descontinuado

JBoss EAP 6 permitia que você continuasse a usar JSF 1.2 com sua implementação de aplicativo ao criar um arquivo jboss-deployment-structure.xml.

JBoss EAP 7 inclui JSF 2.2 e não suporta mais a API JSF 1.2. Se seu aplicativo usa JSF 1.2, você deve regravá-lo para usar JSF 2.2.

Problema de compatibilidade entre JSF 2.1 e JSF 2.2

As APIs JSF 2.1 e JSF 2.2 APIs não são totalmente compatíveis. O valor da constante FACELET_CONTEXT_KEY mudou de com.sun.faces.facelets.FACELET_CONTEXT para javax.faces.FACELET_CONTEXT entre os lançamentos. Este valor é inlined pelo compilador e compilador de código para uma versão não funcionará para outra.

Os aplicativos que contém código similar ao exemplo seguinte e são compilados com a API JSF 2.1 mas são executados no JBoss EAP 7 que utiliza a API JSF 2.2, resulta em um NullPointerException. Para corrigir este problema, você deve recompilar o aplicativo com API JSF 2.2.

Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);

Consulte JAVASERVERFACES_SPEC_PUBLIC-1257 para mais informações.

No JBoss EAP 7, o comportamento do carregamento de classe foi alterado em casos onde múltiplos módulos contêm as mesmas classes ou pacotes.

Presuma que existam dois módulos: MODULE_A e MODULE_B; que dependem uns dos outros e contêm alguns pacotes iguais. No JBoss EAP 6, as classes ou pacotes que eram carregados a partir de dependências sobrepunham-se àqueles especificados no resource-root do arquivo module.xml. Isto significava que MODULE_Avisualizava os pacotes para MODULE_B e MODULE_B visualizava os pacotes para MODULE_A. Este comportamento era confuso e poderia causar conflitos. Este comportamento foi alterado no JBoss EAP 7. Agora as classes ou pacotes especificados pelo resource-root no arquivo module.xml sobrepõem-se àqueles especificados pela dependência. Isto significa que MODULE_A visualiza os pacotes para MODULE_A e MODULE_B visualiza os pacotes para MODULE_B. Isto previne conflitos e proporciona um comportamento mais adequado.

If you have defined custom modules that include resource-root libraries or packages that contain classes that are duplicated in their module dependencies, you might see ClassCastException, LinkageError, class loading errors, or other changes in behavior when you migrate to JBoss EAP 7. To resolve these issues, you must configure your module.xml file to ensure only one version of a class is used. This can be accomplished by using either of the following approaches.

Se você prefere preservar seu comportamento existente, você deve filtrar os pacotes de dependências da resource-root dependente no arquivo module.xml usando o elemento filter. Isto permitirá que você retenha o comportamento existente sem o looping que você notaria com o JBoss EAP 6. A seguir, veja um exemplo de um root-resource que filtra classes em um pacote especificado.

<resource-root path="mycompany.jar">
  <filter>
    <exclude path="com/mycompany/duplicateclassespath"/>
  </filter>
</resource-root>

For more information about modules and class loading, see Class Loading and Modules in the JBoss EAP Development Guide.

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 .

A number of changes have been made to the Amazon Machine Images (AMI) in JBoss EAP 7. This section briefly summarizes some of those changes.

For details on deploying JBoss EAP 7 on Amazon EC2, see Deploying Red Hat JBoss Enterprise Application Platform on Amazon EC2.

The add-user script behavior has changed in JBoss EAP 7 due to a change in password policy. JBoss EAP 6 had a strict password policy. As a result, the add-user script rejected weak passwords that did not satisfy the minimum requirements. In JBoss EAP 7, weak passwords are accepted and a warning is issued. For more information, see Setting Add-User Utility Password Restrictions in the JBoss EAP Configuration Guide.

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, os módulos de extensão e configuração de subsistema para um servidor autônomo configadmin e osgi foram movidos para um arquivo de configuração independente EAP_HOME/standalone/configuration/standalone-osgi.xml. Como você não deve migrar este arquivo de configuração não suportado, a remoção do suporte ao JBoss OSGi não deve afetar a migração de uma configuração de servidor autônomo. Se você modificou qualquer um dos outros arquivos de configuração autônomos para configurar osgi ou configadmin, essas configurações devem ser removidas.

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

Este guia concentra-se nas alterações necessárias para executar e implementar com êxito os aplicativos JBoss EAP 6 no JBoss EAP 7. Se você planeja migrar seus aplicativos diretamente do JBoss EAP 5 para o JBoss EAP 7, há uma série de recursos disponíveis para ajudá-lo planejar e executar sua migração. Sugerimos que você adote a seguinte abordagem.

Antes de planejar a sua migração, você deve estar ciente das alterações feitas no JBoss EAP 6 e no JBoss EAP 7.

O Guia de Migração JBoss EAP 6 abrange as alterações feitas entre o JBoss EAP 5 e o JBoss EAP 6. A seguir, uma lista condensada das alterações mais significativas feitas no JBoss EAP 6.

Consulte Revise o que há de novo e diferente no JBoss EAP 6 no JBoss EAP 6 Guia de Migração para obter uma lista detalhada das alterações feitas nessa versão.

O JBoss EAP 7 é construído na mesma estrutura modular como o JBoss EAP 6 e inclui o mesmo gerenciamento de domínio, configuração de implantação, estrutura de diretório de arquivos e scripts. Ele também usa os mesmos espaço de nomes JNDI padronizados. Porém, o JBoss EAP 7 introduz as seguintes alterações.

Para uma lista completa das alterações, consulte Revise o que há de novo no JBoss EAP 7

Revise todo o conteúdo do Guia de Migração para cada lançamento conhecer os recursos que foram adicionados ou preteridos e para entender a configuração do servidor e as alterações de aplicativo necessárias para executar os aplicativos existentes para a versão.

Como a arquitetura subjacente não foi alterada entre o JBoss EAP 6 e o JBoss EAP 7, muitas das alterações documentadas no Guia de Migração do JBoss EAP 6 ainda são válidas. Por exemplo, alterações documentadas sob Alterações necessárias pela maioria dos aplicativos são relacionadas as alterações de arquitetura subjacentes feitas no JBoss EAP 6, que ainda se aplicam a esta versão. A mudança para o novo sistema modular de carregamento de classe é significativa e afeta o empacotamento e as dependências de quase todas as aplicações JBoss EAP 5. Muitas das alterações listadas sob Alterações dependentes da arquitetura de seus aplicativos e componentes também são válidas. Entretanto, como o JBoss EAP 7 substituiu o servidor Web, ORB e provedor de mensagens; removeu os subsistemas cmp, threads e jaxr e removeu suporte para beans de entidade EJB, você deve consultar este guia para quaisquer alterações relacionadas as áreas destes componentes. Preste atenção especial ao Alterações às configurações de servidor e Alterações na migração de aplicativo detalhadas neste guia antes de começar.

Use a tabela a seguir para encontrar informações sobre como migrar um recurso ou componente específico do JBoss EAP 5 para JBoss EAP 7.