JSR-371 ( MVC 1.0 ) – Com TomCat & TomEE

Logo_MVC_twitter_cmyk
Barista Duke – [DOAG](https://www.doag.org/de/home/)

Neste post veremos como podemos utilizar o MVC 1.0 juntamente com TomCat e TomEE a partir do modulo Ozark-RestEasy que foi comentado no post anterior .

TOMCAT

Iniciaremos pelo Tomcat pois é o que da mais trabalho durante as configurações.

Crie um projeto maven com as seguinte dependências :


<!-- Get the API JARs for Java EE 7 -->

    javax
    javaee-web-api
    7.0


<!-- Weld  -->

    org.jboss.weld.servlet
    weld-servlet-core
    2.4.3.Final


<!-- RESTEasy -->

    org.jboss.resteasy
    resteasy-cdi
    3.1.4.Final


    org.jboss.resteasy
    resteasy-servlet-initializer
     3.1.4.Final


<!-- Bean Validation -->

    org.hibernate
    hibernate-validator
    5.4.1.Final


<!-- MVC + Ozark for RESTEasy-->

    javax.mvc
    javax.mvc-api
    1.0-pr


    org.mvc-spec.ozark
    ozark-resteasy
    1.0.0-m03

 

feito isso, seguiremos para configuração dos arquivos beans.xml e context.xml :

dentro da pasta /src/main/webapp/WEB-INF crie um arquivo beans.xml com o seguinte conteudo :

 



 

agora na pasta src/main/resources/META-INF crie um arquivo context.xml com o seguinte conteudo :

 


   


 

Este arquivo é essencial para um correto funcionamento do CDI com o Tomcat, o mesmo é descrito aqui Weld Documentação .

Logo também devemos criar um aquivo web.xml na pasta src/main/webapp/WEB-INF com o seguinte conteúdo :

 


		
   		org.jboss.weld.environment.servlet.Listener


  
    BeanManager
    javax.enterprise.inject.spi.BeanManager
  

  <!--http://docs.jboss.org/resteasy/docs/3.1.4.Final/userguide/html_single/index.html#d4e143 -->
  
    resteasy.injector.factory
    org.jboss.resteasy.cdi.CdiInjectorFactory
  


 

Com tudo pronto, podemos da inicio a um Hello Tomcat seguindo os post anteriores.

TOMEE

O TomEE utilizar a CXF como implementação do Jax-RS, porem a Ozark no momento não suporta por causa de bugs no CXF causando problemas com a utilização do Ozark.

Como alternativa, podemos utilizar o modulo Ozark-RestEasy para o seu funcionamento.

crie um projeto maven com o seguinte conteúdo :


    javax.mvc
    javax.mvc-api
    1.0-pr



    org.mvc-spec.ozark
    ozark-resteasy
    1.0.0-m03



    org.jboss.resteasy
    resteasy-cdi
    3.1.4.Final



    org.jboss.resteasy
    resteasy-servlet-initializer
    3.1.4.Final



    javax
    javaee-web-api
    8.0
    provided

 

Da mesma forma que vimos para o TomCat vamos precisar configurar nosso XML, mas ao invés de 3, serão apenas o beans.xml e o web.xml.

o conteúdo do web.xml na pasta src/main/webapp/WEB-INF com o seguinte conteúdo :

 



tomee
  
	resteasy.injector.factory
	org.jboss.resteasy.cdi.CdiInjectorFactory
	

Com tudo pronto, podemos da inicio a um Hello TomEE seguindo os post anteriores.

Bem isso é tudo, aqui aprendemos  como fazer a api MVC 1.0 funcionar no TomCat & TomEE, espero que gostem, o código pode se encontrado aqui .

Atualmente a SPEC esta em Public Review e também estão movendo para Fundação Eclipse sobre o Projeto EE4J.

Sinta-se livre para se juntar à nossa lista de discussão e nos informar o que você acha. Você pode publicar suas opiniões na lista ou registrar um problema no rastreador de problemas.

REFERÊNCIAS

 

Anúncios

13 comentários sobre “JSR-371 ( MVC 1.0 ) – Com TomCat & TomEE

  1. Ola @Ice-Man, obrigado por visita o blog, espero que tenha gostado.

    O exemplo nesse blog funcionar com a ultima versão do TomCat, que no caso é o 9 . Mas para funcionar tem que seguir o que esta neste post .

    Pois se utilizar com a ultima versão da MVC M04-SNAPSHOT vai falhar, estou fazendo uns teste para fazer funcionar .

    Curtir

    1. Opa, consegui fazer funcionar no TomCat 8.0.27 (via netBeans8.2) c/as dependências:
      * MVC-api 1.0-pr;
      * Ozark.1.0.0-m03 ;
      * Weld-servlet-core 3.0.4.Final ; e
      * (adicionei) JSTL 1.2 .

      (Ob.s: logo no começo já fui colocando o bean-discovery-mode=”annotated”; o interessante foi q o Ozark(/RestEast) continuou atendendo as Request’s normalmente. O problema é que a Injeção de Dependências começou a falhar: aí eu me tokei, né, FCQF: c/o scan “annotated” é claro que as instancias só seriam gerenciadas se Anotadas (e, de preferencia, como prescreve as especificação do CDI, c/um Scope definido). Ainda assim, não funcionou: até pensei em postar um comentário perguntando se deveria adicionar uma issue na spec.)
      Foi aí q eu me dei conta: será q eu deveria anotar a minha Controller com @Named e @RequestScoped ??! Se acha que poderia sugerir à spec que (tudo q esteja com annotation @Controller ) já seja por default o @RequestScoped ??!

      Curtir

      1. Ola @Ice-Man, tudo bem ?

        quando você usa com o bean-discovery-mode=”annotated” a mesma ira falhar, pois não tem nenhum SCOPE do CDI no seu controller, se utilizado com bean-discovery-mode=”annotated” você deve no seu Controller adicionar o @RequestScoped para o mesmo funcionar.

        Se voce anotar seu controler com @Named isso tambem vai falhar, pois não tem sentindo algum usar essa annotaçao, pois o Controller não deve ser acessado na view tipo : ${meucontroller.getAlgumMetodo} .

        Quando você @Named utiliza isso na ultima versao do Ozark ele ira reportar um log de aviso para ser removido .
        Quando você usa um controllador com bean-discovery-mode=”annotated” ultima versao do Ozark e não informar nenhum scope, o Ozark ira lançar um Exception informando que o Controllar não é um Bean gerenciado pelo CDI e vai recomendar adicionar um SCOPE na sua classe .

        Não tenho certeza, mas acho que isso já tem o default o @RequestScoped , porem fica no ModelImpl . Por isso o uso do beans.xml com bean-discovery-mode=”all” .

        Você também pode levantar uma questão dessa no ISSUES da Ozark ou na lista de da mesma :

        https://github.com/mvc-spec/ozark/issues
        https://groups.google.com/forum/#!forum/ozark-users

        Recomendo você utilizar a ultima versão do Ozark para ir testando as coisas .

        Curtir

  2. @Daniel,
    Com a release Ozark 1.0.0-m03 , eu consegui fazer funcionar até no TomCat7.
    Porem, quando eu usa a v 1.0.0-m04-SNAPSHOT
    , sempre apresenta o mesmo erro:

    GRAVE: ContainerBase.addChild: start:
    org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/tomcat-mvc]]
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:162)

    Caused by: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
    at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:724)

    Isso é um sinal que deve-se adicionar mais outra dependência??!

    Derlon

    Curtir

  3. @Daniel, blz?!!
    Eu comecei a implementar/adicionar as funcionalidade do sample `Validação´ no projeto sample `TomCat´: observei que, quando a Aplicação faz um submit com Validações NÃO satisfeitas, é feito um dispatch p/a mesma página, porém os dados informados válidos não são mantidos; ou seja, é o caso que precisamos de algo como famoso keepAlive e, como forma + simples de resolver isso, decidi bindar o value dos imputText nos atributos de uma instancia JUG como atributo no meu Controller: e p/isso preciso anotá-la com @Named .

    Daniel say: […]seu controler com @Named isso tambem vai falhar, pois não tem sentindo algum usar essa annotaçao, pois o Controller não deve ser acessado na view tipo : ${meucontroller.getAlgumMetodo}[…]
    Sei que a própria documentação do CDI desencoraja seu uso (não obstante, isto ser um tanto quanto ambíguo). Desta forma (o workaround):
    @RequestScoped @Named(“validacao”) // @ConversationScoped
    public class ValidacaoController {

    private JUG jug = new JUG();

    Curtido por 1 pessoa

    1. e na form.JSP:

      ...
      Email:

      "eu atualizei o pom.xml para ultima versão
      [...]"

      Ah, consegui resolver o meu problema! Ker dizer: consegui e não consegui. Baixei o seu sample/projeto TomCat atualizado e fui reimplementando tudo aos pouquinhos (baby steps p/não ter erro, né?) e por um momento cheguei a pensar q a causa-raiz do problema fosse a questão das lambdas, pois no log tinha observado at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.lambda$null$0(ReentrantMapBackedComputingCache.java:55), mas contrário à minha expectativa :O ,foi dando tudo certo, ou seja o sem sample tá perfeitinho (é provável que já estava mesmo antes da atualização xD ).


      (Obs.: este comment tá ficando long d+: vou kebra-lo em 2)

      Curtir

    2. e na form.JSP:

      ...
      Email:

      “eu atualizei o pom.xml para ultima versão
      […]”

      Ah, consegui resolver o meu problema! Ker dizer: consegui e não consegui. Baixei o seu sample/projeto TomCat atualizado e fui reimplementando tudo aos pouquinhos (baby steps p/não ter erro, né?) e por um momento cheguei a pensar q a causa-raiz do problema fosse a questão das lambdas, pois no log tinha observado at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.lambda$null$0(ReentrantMapBackedComputingCache.java:55), mas contrário à minha expectativa :O ,foi dando tudo certo, ou seja o sem sample tá perfeitinho (é provável que já estava mesmo antes da atualização xD ).


      (Obs.: este comment tá ficando long d+: vou kebra-lo em 2)

      Curtir

  4. Ola Derlon,

    que bom que funcionou.

    novamente, voce não precisa adicionar o @Named no Controller .

    voce não vai fazer ${validacao.jug.nome} na sua view.

    no JSR-371 voce tem duas maneira de exibir para a view :

    1 – usando a Moldels
    2 – CDI @Named + RequestScoped ou @Model -> nas usa entidades.

    exemplo :

    // minha entidade
    @Named(“JUG)
    @RequestScoped
    public class Jug { // meus gets e setts}

    //meu controller:

    @Controller
    @Path(“meuEndPoint”)
    public MeuController {

    @Inject
    private Jug jug;

    @GET
    @Path(“inserir”)
    @View(“inserir.jsp”)
    public void salvarJug(JUGDTO jugDto) {

    this.jug.setNome(jugDto.getName);
    }

    //na minha View.

    Ola ${jug.nome} !

    Curtir

    1. Olá Daniel,
      (antes de qualquer coisa, desculpe pelo double post)

      Opa! A alternativa ‘1‘ sussa, sim é a que mais se aproxima do estado-da-arte! Inclusive, creio até que essa ‘Model'(do MVC-api) foi inspirada na Result do vRaptor. (Na verdade, já estava implementado assim, só q estava após o bloco do if (bindingResult.isFailed() ). Genial! e simples)
      Entretanto, com relação à alternativa ‘2‘ tenho minhas reservas pois, da mesma forma que encorajado no Seam-framework, acabamos colocando (todas) as Entidades-de-Negócio da App como instancias gerenciadas pelo DI Container: imagina o footPrint(gasto de memória, recursos, etc.) a mais, principalmente se o Domain Model for vitaminado do comportamento (NOT anemic Domain Model).
      Parabéns, continuem com ótimo trabalho (MVC-api/RIOzark)!!!

      Curtir

      1. Ola Derlon,

        O Model é obrigatório todas a implementações usar, e também acho mais simples.

        Muita coisa na MVC-API tem algumas semelhanças com Vraptor(nunca usei) e com Spring .

        Sobre usar o CDI como no exemplo é opcional(pela spec altamente recomendado) , porem nem toda view template tem suporte a cdi para exibir na view, atualmente as que suporta como o exemplo no ultimo comentário são ; JSP, Facelets e Thymleaf .

        Mais foi um excelente comentário e consegui apredendo algo super maneiro com você.

        mais uma vez muito obrigado . : )

        aqui tem mais alguns exemplos – > https://github.com/SouJava-Rio/soujava-rio-labs/tree/master/MVC1.0-samples

        Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s