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

return void();

É uma pequeneza mas eu gostaria muito que as linguagens da família do C permitissem retornar void quando a função retorna void . Escrever da forma a seguir me aborrece. public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null)      {        log("x was null");        return;      }      bar(x, "default");    } } Eu ficaria mais feliz escrevendo assim: public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null) return log("x was null");      bar(x, "default");     } }
Postar um comentário
Leia mais

.NET COM Interop, IStream e Visual Studio

Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream , e me deparei com um problema interessante: interoperabilidade com .NET. Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto. Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação. Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream , uma interface definida pelo sistema. Pelo método do callable wrapper , a ferramenta assume que as interfaces mencionadas integram o componente...
Postar um comentário
Leia mais

Eclipse PDE com Gradle

Na virada de 2016 para 2017, adotamos oficialmente o Gradle como ferramenta de construção de software na Prodist. A fila da migração está fluindo confortavelmente desde então. Já temos as provas de conceito necessárias para todos os projetos, inclusive os projetos nativos para compilador C++. Para fontes Java usamos Eclipse. Integramos projetos Gradle ao Eclipse usando Buildship . Acho que o Buildship ainda tem um longo caminho pela frente, mas realiza tudo o que necessitamos. Já estamos entregando com base nesse esquema. O problema mais importante que encontramos foi na integração de projetos OSGi. No Eclipse, trabalhamos projetos OSGi com o PDE. Nosso ciclo de desenvolvimento inclui rodar configurações "OSGi Framework" no Eclipse para teste. Infelizmente, o PDE assume uma estrutura de projeto própria e não funciona corretamente caso contrário. Estes problemas estão registrados em bugs como, por exemplo, o  bug 153023 . Nossos projetos OSGi com Gradle usam o layout ...
Postar um comentário
Leia mais