Glassfish v3 EJB e Standalone Client

03:27 in glassfish, glassfish v3, Java, pt-br, Swing

Não sei se muita gente usa isso, mas eu uso, um client swing, para um modulo EJB, recentemente, saiu a versão V3 do glassfish, e lá fui eu tentar comunicar com o container EJB, até a versão v2 as bibliotecas necessarias eram o JavaEE 5, appserv-rt, appserv-deployment, appserv-admin e o appserver-ext, isso devia tar entorno de uns 20MB de bibliotecas.

Seguindo ao FAQ do Glassfish eu devia adicionar somente o GF-CLIENT no classpath da applicação, um jarzinho de alguns KB, e adivinha, não funcinou, depois de uma extensiva busca não encontrei solução e cheguei a conclusão que, NÃO ACREDITE NO FAQ DO CLASSFISH. Além desse tal de gf-client, eles aconselham vc a usar o construtor sem argumentos da classe InitialContext, se vc quiser conectar SOMENTE EM LOCALHOST use o construtor sem argumetos.

Criei um projeto, adicionei todos os jars do GLASSFISHV3_HOME/glassfish/modules, a conexão funcionou 100%, agora era ver quais jars iriam manter minha conexão ativa, e fui removendo 1 a 1 os jars e testando, chegando finalmente a 6MB de jars (diminui bastante comparado com as versões anteriores), que devem estar no seu classpath, listados abaixo

• auto-depends


• common-util


• config-api


• config


• config-types


• dol


• deployment-common


• ejb.security


• ejb-container


• glassfish-naming


• glassfish-api


• glassfish-corba-orb


• glassfish-corba-omgapi


• glassfish-corba-orbgeneric


• glassfish-corba-codegen


• glassfish-corba-newtimer


• glassfish-corba-csiv2-idl


• glassfish-corba-asm


• gmbal


• hk2-core


• internal-api


• javax.resource


• java.ejb


• kernel


• management-api


• orb-connector


• orb-iiop


• security


• tiger-types-osgi

E nenhum dos gf-QUALQUER_COISA é necessario, essa aplicação está em produção desse modo. Alguns desses jars são encontrados em repositorios maven como tiger-types-osgi, eu optei por adicionar a maioria no repositorio local e esses mesmo para não ter problema.

Read more

Swing e TestUnit (JUnit)

07:09 in Java, JUnit, Swing, Testes

Quem já mecheu com Swing conheçe o parto que é testar as telas. Pensar nas mil possibilidades se fazer cagada em uma tela. Impossivel prever o total de coisas que um usuário consegue fazer. Para facilitar esses testes surgiu o JUnit, automatizando os testes. Não vou entrar em detalhes sobre o TDD, existe muita informação por ai.

Mas algum tempo atrás procurei por algo para automatizar os testes em Interfaces gráficas. Porém nada do que eu achei era o que eu buscava. Não queria ter que abrir a tela e inserir valores. Gostaria de fazer isso via código de forma automatica, como o JUnit, em busca de um resultado esperado. Vi sobre o Maraton, FestSwing, e em todos eu tinha que abrir a droga das telas para testar. Algo que não me agradou nem um pouco.

Então deixei de lado isso. Porém alguns dias atraz me veio uma ideia meio louca de se fazer isso. Criei uma classe que encapsula o frame. e atraves dela consigo recuperar os compoenentes da tela e simular as ações. Exatemente o que eu queria. Automatizar a porcaria do teste (:

Image o seguinte JInternalFrame:



A ação do botão se resume a alterar o texto de JInternalFrame para Clicked.
E ai? como fazer para testar esse esquema?

public class TestFrameWithMock {

   private SwingTester mock;



   public TestFrameWithMock() {

       mock = new SwingTester(new TesteInternal());

   }



   @Test

   public void shouldChangeTextWhenButtonWasClicked(){

       JButton btn = (JButton) mock.getFieldReflect("jButton1");

       JTextField tf = (JTextField) mock.getFieldReflect("jTextField1");

       assertEquals("JInternalFrame", tf.getText());

       btn.doClick();

       assertEquals("Clicked", tf.getText());

   }

}

E ai alguém ai percebeu como é simples o esquema? E nenhuma tela é visivel. A maioria das ferramentes você deveria abrir cada JInternalFrame, um por um e testa-lo. Assim desse modo com a Classe SwingTester ele não é visivel.

Como podem perceber o TesteInternal (JInternalFrame da imagem) é passado como parametro. E atraves dele é possivel recuperar os compoenentes da tela atraves do atributo name de cada um ou atraves do nome da variavel via reflection (que foi usado nesse teste acima). E o teste executa sem problemas.

Foi a abordagem que achei mais legal. Em breve for colocar isso ai no github, se eu lembrar e vcs podem analisar e testar.

Read more