Pular para o conteúdo principal

GWT DevMode com EJB

Este ano estamos iniciando nossa convivência com sistemas interativos via web e escolhemos o Google Web Toolkit para nos apoiar, convictos em jamais usar pré-processamento de HTML no servidor.

Enquanto este toolkit (na versão 2.4) nos pareceu desde o início uma coisa totalmente excelente, uma preocupação se manteve firme: o ciclo de desenvolvimento ótimo do GWT exige o uso do DevMode.

O DevMode do GWT é um truque excelente que permite ao desenvolvedor usar um depurador Java para rastrar a execução do programa que roda no user agent. Como GWT é fundamentalmente um compilador de Java para Javascript, depurar o código-fonte de produção seria no mínimo desagradável.

A configuração padrão do DevMode (na versão 2.4) inclui o web container Jetty para servir o HTML, JS, CSS, Servlets e tudo o mais que compõe o programa. O Jetty é um container simples e não inclui, entre outras coisas, uma implementação de JPA ou EJB.

Ora, como este projeto pode permanecer confortável? Eventualmente a "camada de negócio" deverá ser movida de Servlets GWT para componentes EJB. Será preciso embutir um ejb container no projeto e fazer as ligações manualmente?

Não! É perfeitamente possível usar o GWT DevMode com seu servidor de aplicações favorito!

O fato é que o DevMode não exige o Jetty e na realidade é totalmente independente do seu web container. O DevMode é um serviço que oferece algum tipo de interface RPC usada pelo próprio programa GWT.

É possível usar o DevMode com o programa implantado em qualquer web container. É possível, por exemplo, implantar o programa no JBoss AS 7 e então usar um user agent qualquer para acessar o endereço publicado pelo JBoss AS 7 com o DevMode.

Para fazer isso é necessário:
  1. acrescentar o parâmetro -noserver aos argumentos do DevMode
  2. modificar o parâmetro -startupUrl , nos argumentos do DevMode, para o local de publicação do seu programa
 Estas coisas são facilmente realizadas na Debug Configuration do Eclipse.

Para depurar completamente o seu programa, você deve:
  1. iniciar o servidor de aplicação no modo Debug
  2. publicar seu programa no servidor de aplicação
  3. iniciar o GWT DevMode configurado adequadamente
Desse modo, para um programa publicado em http://localhost:8080/sandbox, o GWT DevMode instruirá você a acessar o endereço http://localhost:8080/sandbox?gwt.codesvr=127.0.0.1:9997 ou algo parecido.

Observe que o endereço do GWT DevMode é um argumento para o programa Javascript; a ligação entre uma coisa e a outra é indireta o suficiente para permitir o programa ser hospedado em um servidor de aplicação completo, sem prejudicar o ciclo de desenvolvimento.

Marcadores:

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Análise vs. Projeto

Eu diria que a ruptura entre Análise e o Projeto acontece quando acabam as considerações sobre o problema e começam as considerações sobre a solução. Em outras palavras, o papel do Analista é considerar o problema, enquanto o papel do Projetista é o de considerar a solução. Assim, o Analista aparece quando um problema aparece, e dá lugar ao Projetista quando o problema foi devidamente analisado, restando produzir para ele uma solução. E diria que a ruptura entre a Especificação e a Implementação acontece quando acabam os artefatos para consumo por humanos e começam os artefatos para consumo por máquinas. Em outras palavras, o papel do Especificador é produzir artefatos para consumo por humanos, enquanto o papel do Implementador é produzir artefatos para consumo por máquinas. Assim, o Especificador aparece quando a atividade é produzir efeitos sobre humanos, e dá lugar ao Implementador quando os humanos estão devidamente satisfeitos e a atividade prossegue para produzir efeito...
Postar um comentário
Leia mais

Por que goto é considerado prejudicial?

Recentemente, o Fabiano Vasconcelos abriu uma discussão no Grupo de Usuários de C e C++: De cara eu vi algo aqui um pouco estranho, se que o amigo Márcio me permite comentar: que muitos programadores, inclusive eu (se que posso ser rotulado como programador) foram instruídos com o princípio de NUNCA usar o goto, por ser considerado um mau estilo de programação. Durante a discussão, o Eduardo Vieira puxou um artigo da KernelTrap sobre uma discussão similar ocorrida no grupo de desenvolvimento do Linux, onde Robert Wilken disse o seguinte: In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read. É preciso colocar a máxima "goto considered harmful" na perspectiva histórica adequada. Acredito que praticamente todo programador trein...
Postar um comentário
Leia mais

Servidor e usuário COM na mesma "solution"

 Um dos objetivos da próxima iteração no meu projeto atual é quebrar o sistema em mais pedaços, e levantar os pedaços um nível de abstração até componentes COM. Uma das consequências é substituir diversas ligações mais estáticas e torná-las ligações mais dinâmicas através do COM. Tipicamente, um programa usuário de um componente COM, escrito para o Visual Studio, usará a diretiva #import para incluir na unidade de tradução C++ as declarações necessárias. Isso implica que o componente deve estar instalado na máquina que constrói o programa. O que fazer quando o componente em questão está no mesmo lote de construção que o programa usuário? A solução inicial é criar uma dependência de construção tal que o componente seja sempre construído primeiro, e usar um post-build event ao projeto do componente para registrá-lo no sistema. Desse modo, na construção do programa, o ambiente estará correto. Eu considero este arranjo prejudicial. Minha melhor razão é esta: o servidor de const...
Postar um comentário
Leia mais