Página Inicial>Relacionado com a programação>Código fonte JAVA
Baixar

Amostras Java EE 7

Este espaço de trabalho consiste em amostras Java EE 7 e testes de unidade. Eles são categorizados em diretórios diferentes, um para cada Tecnologia/JSR.

Algumas amostras/testes possuem documentação, caso contrário, leia o código. O livro Java EE 7 Essentials refere-se à maioria desses exemplos e fornece uma explicação. Sinta-se à vontade para adicionar documentos e enviar uma solicitação pull.

Como correr?

As amostras são testadas em Payara, GlassFish, Wildfly e outros usando o ecossistema Arquillian.

Uma breve instrução sobre como clonar, construir, importar e executar os exemplos em sua máquina local que @radcortez fornece neste vídeo de exemplo https://www.youtube.com/watch?v=BB4b-Yz9cF0

Apenas um perfil de contêiner pode estar ativo por vez, caso contrário, haverá conflitos de dependência.

Existem 16 perfis de contêiner disponíveis, para 6 servidores diferentes:

  • Payara e GlassFish

    • payara-ci-managed

      Este perfil instalará um servidor Payara e iniciará o servidor por exemplo. Útil para servidores de CI. A versão do Payara usada pode ser definida por meio da propriedade payara.version . Este é o perfil padrão e não precisa ser especificado explicitamente.

    • payara-embedded

      Este perfil usa o servidor integrado Payara e é executado na mesma JVM que TestClass. Útil para desenvolvimento, mas tem a desvantagem de iniciar o servidor por exemplo.

    • payara-remote

      Este perfil requer que você inicie um servidor Payara fora da compilação. Cada amostra reutilizará esta instância para executar os testes. Útil para desenvolvimento para evitar o custo de inicialização do servidor por amostra.

      Este perfil suporta alguns testes para definir o local onde o Payara está instalado por meio da propriedade do sistema glassfishRemote_gfHome . Por exemplo

      -DglassfishRemote_gfHome=/opt/payara171

      Isso é usado para enviar comandos asadmin para criar recursos de contêiner, como usuários em um repositório de identidades.

    • glassfish-embedded

      Este perfil usa o servidor incorporado GlassFish e é executado na mesma JVM que TestClass. Útil para desenvolvimento, mas tem a desvantagem de iniciar o servidor por exemplo.

    • glassfish-remote

      Este perfil requer que você inicie um servidor GlassFish fora da compilação. Cada amostra reutilizará esta instância para executar os testes. Útil para desenvolvimento para evitar o custo de inicialização do servidor por amostra.

      Este perfil suporta alguns testes para definir o local onde o GlassFish está instalado por meio da propriedade do sistema glassfishRemote_gfHome . Por exemplo

      -DglassfishRemote_gfHome=/opt/glassfish41

      Isso é usado para enviar comandos asadmin para criar recursos de contêiner, como usuários em um repositório de identidades.

  • mosca selvagem

    • wildfly-ci-managed

      Este perfil instalará um servidor Wildfly e iniciará o servidor por exemplo. Útil para servidores de CI. A versão do WildFly usada pode ser definida por meio da propriedade wildfly.version .

    • wildfly-embedded

      Este perfil é quase idêntico ao gerenciado pelo wildfly-ci. Ele instalará o mesmo servidor Wildfly e iniciará esse servidor por amostra novamente, mas em vez disso usará o conector incorporado Arquillian para executá-lo na mesma JVM. Útil para servidores de CI. A versão do WildFly usada pode ser definida por meio da propriedade wildfly.version .

    • wildfly-remote

      Este perfil requer que você inicie um servidor Wildfly fora da compilação. Cada amostra reutilizará esta instância para executar os testes. Útil para desenvolvimento para evitar o custo de inicialização do servidor por amostra.

    • wildfly-swarm

      Este perfil usa WildFly Swarm, que permite construir uberjars que contenham apenas o suficiente do servidor de aplicativos WildFly. Aqui, as partes do WildFly incluídas são selecionadas com base na inspeção do aplicativo e na procura das APIs Java EE que são realmente usadas. A versão do WildFly Swarm usada pode ser definida por meio da propriedade wildfly.swarm.version .

  • TomEE

    • tomee-ci-managed

      Este perfil instalará um servidor TomEE e iniciará esse servidor por exemplo. Útil para servidores de CI. Este perfil não pode se conectar a um servidor em execução.

      Observe que a versão do TomEE a ser utilizada deve estar presente em um repositório maven disponível. Os padrões neste perfil assumem que o adaptador arquillian e o servidor TomEE possuem a mesma versão. Por exemplo, ambos 7.0.0.

      Para usar um servidor TomEE que não está disponível no maven central, uma maneira de usá-lo para os exemplos é instalá-lo em um .m2 local da seguinte forma:

      Clone o repositório TomEE:

      git clone https://github.com/apache/tomee cd tomee

      Mude para a versão desejada, se necessário, depois construa e instale em .m2:

      mvn clean install -pl tomee/apache-tomee -am -Dmaven.test.skip=true

      mvn clean install -pl arquillian -amd -Dmaven.test.skip=true

      Certifique-se de que a versão instalada (consulte pom.xml no projeto TomEE) corresponda a tomee.version na seção de propriedades na raiz pom.xml do projeto de amostras.

    • tomee-embedded

      Este perfil usa o servidor integrado TomEE e é executado na mesma JVM que TestClass.

  • Liberdade

    • liberty-managed

      Este perfil iniciará o servidor Liberty por amostra e, opcionalmente, se conectará a um servidor em execução que pode ser inicializado fora da construção (com a restrição de que este servidor tenha que ser executado no host onde os testes são executados usando o mesmo usuário ).

      Para conectar-se a um servidor em execução, a propriedade do sistema org.jboss.arquillian.container.was.wlp_managed_8_5.allowConnectingToRunningServer deve ser definida como true. Por exemplo

      -Dorg.jboss.arquillian.container.was.wlp_managed_8_5.allowConnectingToRunningServer=true

      Este perfil requer que você configure o local onde o Liberty está instalado por meio da propriedade do sistema libertyManagedArquillian_wlpHome . Por exemplo

      -DlibertyManagedArquillian_wlpHome=/opt/wlp

      Este perfil também requer que o recurso localConnector seja configurado em server.xml e, se todos os testes forem executados, o recurso javaee-7.0, por exemplo 

      < featureManager >
    < feature >javaee-7.0</ feature >
    < feature >localConnector-1.0</ feature >
</ featureManager >

      Para versões mais antigas do Liberty (anteriores a 16.0.0.0) para que os testes JASPIC sejam tentados a serem executados, é necessário um cheat que crie um grupo no registro de usuário interno do Liberty: 

      < basicRegistry id = " basic " >
    < group name = " architect " />
</ basicRegistry >

      Este cheat não é necessário para as versões mais recentes do Liberty (16.0.0.0/2016.7 e posteriores)

    • liberty-ci-managed

      Este perfil fará download e instalará um servidor Liberty e iniciará o servidor por amostra. Útil para servidores de CI. Observe que este não é um servidor incorporado real, mas um servidor normal. Agora é chamado de "incorporado" porque nenhuma instalação separada é necessária, pois é baixado automaticamente.

  • Weblógica

    • weblogic-remote

      Este perfil requer que você inicialize um servidor WebLogic fora da construção. Cada amostra reutilizará esta instância para executar os testes.

      Este perfil requer que você defina o local onde o WebLogic está instalado por meio da propriedade de sistema weblogicRemoteArquillian_wlHome . Por exemplo

      -DweblogicRemoteArquillian_wlHome=/opt/wls12210

      O nome de usuário/senha padrão é "admin" e "admin007", respectivamente. Isso pode ser alterado usando as propriedades do sistema weblogicRemoteArquillian_adminUserName e weblogicRemoteArquillian_adminPassword . Por exemplo

      -DweblogicRemoteArquillian_adminUserName=myuser -DweblogicRemoteArquillian_adminPassword=mypassword

  • gato

    • tomcat-remote

      Este perfil requer que você inicie um servidor Tomcat simples (8.5 ou 9) fora da compilação. Cada amostra reutilizará esta instância para executar os testes.

      O Tomcat suporta amostras que fazem uso de Servlet, JSP, Expression Language (EL), WebSocket e JASPIC.

      Este perfil requer que você habilite o JMX no Tomcat. Isso pode ser feito adicionando o seguinte a [tomcat home]/bin/catalina.sh : 

       JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=8089 -Dcom.sun.management.jmxremote=true "
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false "
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=localhost "

      Este perfil também exige que você defina um nome de usuário ( tomcat ) e uma senha ( manager ) para o aplicativo de gerenciamento em tomcat-users.xml . Consulte o arquivo test-utils/src/main/resources/tomcat-users.xml neste repositório para obter um exemplo completo.

      Esteja ciente de que isso só deve ser feito para uma instância do Tomcat usada exclusivamente para teste, pois o procedimento acima tornará a instalação do Tomcat totalmente insegura!

    • tomcat-ci-managed

      Este perfil instalará um servidor Tomcat e iniciará o servidor por exemplo. Útil para servidores de CI. A versão do Tomcat usada pode ser definida por meio da propriedade tomcat.version .

Os contêineres que baixam e instalam um servidor (os perfis gerenciados por *-ci) permitem substituir a versão usada, por exemplo:

  • -Dpayara.version=4.1.1.163

    Isso mudará a versão atual (por exemplo, 4.1.1.171.1) para 4.1.1.163 para fins de teste do Payara.

  • -Dglassfish.version=4.1

    Isto mudará a versão atual (por exemplo, 4.1.1) para 4.1 para fins de teste do GlassFish.

  • -Dwildfly.version=8.1.0.Final

    Isso mudará a versão atual (por exemplo, 10.1.0.Final) para 8.1.0.Final para WildFly.

Para executá-los no console faça :

  1. No terminal, mvn test -fae no diretório de nível superior para iniciar os testes do perfil padrão.

Ao desenvolvê-los e executá-los no IDE, lembre-se de ativar o perfil antes de executar o teste.

Para saber mais sobre o Arquillian consulte os Guias do Arquillian

Para executar apenas um subconjunto dos testes, faça no diretório de nível superior :

  1. Instale dependências de nível superior: mvn clean install -pl "test-utils,util" -am
  2. cd no módulo desejado, por exemplo: cd jaspic
  3. Execute testes no servidor desejado, por exemplo: mvn clean test -P liberty-ci-managed

Como contribuir

Com a sua ajuda podemos melhorar este conjunto de amostras, aprender uns com os outros e fazer crescer a comunidade cheia de pessoas apaixonadas que se preocupam com a tecnologia, inovação e qualidade do código. Cada contribuição importa!

Há um monte de coisas que você deve ter em mente antes de enviar uma solicitação pull, para que possamos facilmente incorporar todas as novidades no branch master.

Os testes padrão são baseados em jUnit - por exemplo, este commit. A nomenclatura das classes de teste deve estar em conformidade com os padrões de nomenclatura infalíveis **/*Test.java , **/*Test*.java ou **/*TestCase.java .

Por uma questão de clareza e consistência, e para minimizar a complexidade inicial, preferimos testes jUnit padrão usando Java, com ajudantes adicionais HtmlUnit, Hamcrest e, claro, Arquillian. Por favor, não use alternativas para essas tecnologias. Se alguma nova dependência tiver que ser introduzida neste projeto, ela deverá fornecer algo que não seja coberto por essas dependências existentes.

Alguns princípios de codificação

  • Ao criar um novo arquivo fonte, não coloque (ou copie) nenhum cabeçalho de licença, pois usamos licença de nível superior (MIT) para cada arquivo neste repositório.
  • Siga o perfil de formatação do código da comunidade JBoss conforme definido no repositório jboss/ide-config. Os detalhes são explicados ali, assim como as configurações para Eclipse, IntelliJ e NetBeans.

Pequenas dicas do Git

  • Certifique-se de que seu garfo esteja sempre atualizado. Basta executar git pull upstream master e você estará pronto para hackear.
  • Ao desenvolver novos recursos, crie um branch de recursos para que possamos incorporar suas alterações sem problemas. Também é conveniente para você, pois você pode trabalhar em algumas coisas em paralelo;) Para criar um branch de recurso e mudar para ele de uma só vez, você pode usar git checkout -b my_new_cool_feature

É isso! Bem-vindo à comunidade!

Trabalho de CI

Os trabalhos de CI são executados pelo Travis. Observe que, pela própria natureza das amostras fornecidas aqui, é perfeitamente normal que nem todos os testes sejam aprovados. Isso normalmente indicaria um bug no servidor no qual as amostras são executadas. Se você acha que é realmente o teste que está com defeito, envie um problema ou forneça uma correção a um PR.

Execute cada amostra no Docker

  • Instale o cliente Docker em http://boot2docker.io

  • Crie a amostra que você deseja executar como

    mvn clean package -DskipTests

    Por exemplo:

    mvn -f jaxrs/jaxrs-client/pom.xml clean package -DskipTests

  • Altere a segunda linha no Dockerfile para especificar o local do arquivo WAR gerado

  • Execute boot2docker e dê o comando

    docker build -it -p 80:8080 javaee7-sample

  • Em um shell diferente, descubra o endereço IP do contêiner em execução como:

    boot2docker ip

  • Acesse a amostra como http://IP_ADDRESS:80/jaxrs-client/webresources/persons. O URL exato seria diferente com base na amostra.

Expandir
Informações adicionais
Aplicativos Relacionados
Recomendado para você
Informações Relacionadas Todos