26 Apr 07 Testando aplicações que usam JavaMail

Acho que mais alguem alem de mim ja teve problemas para testar aplicações que utilizam JavaMail …

Bom, quando eu precisei disto, não encontrei nenhum tipo de mock, e o que consegui fazer foi criar um monte de contas fake em um servidor de e-mails local …

Mas agora ja existe o Mock Java Mail que permite o envio/recebimento de mensagens para uma caixa postal “in memory”, graças a plugabilidade da API Java Mail.

Basta adicionar o jar do Mock Java Mail no classpath e começar a brincar …

Por exemplo, este código que normalmente envia e-mails “de verdade”, para um servidor “de verdade” vai apenas enviar os e-mails para esta caixa postal “fake”.

MimeMessage msg = new MimeMessage();
...
msg.setRecipients(TO,"kohsuke.kawaguchi@sun.com");
Transport.send(msg);

E você pode ler estes e-mails programaticamente assim:

List inbox = Mailbox.get("kohsuke.kawaguchi@sun.com");
assertEquals(inbox.size(),1); // o e-mail foi enviado realmente?

Ou então utilizando a API do próprio JavaMail para receber os e-mails.

Session session = ...;
Store store = session.getStore("pop3");  // poderia ser imap também

// conectar a caixa postal
store.connect("sun.com","kohsuke.kawaguchi","anything");

Folder folder = store.getFolder("INBOX");
folder.open(Folder.READ_WRITE);
Message[] msgs = folder.getMessages();

Vou dar mais uma pesquisada, mas só isto ja esta perfeito!!

Só falta ter uma forma de testar envios com erro também, por exemplo simular uma caixa postal inválida

Estou baixando os fontes e o jar para dar uma olhada na API, mas fica a dica, a proxima aplicação que fizerem que utilizar JavaMail, ja não precisa mais ser tão complicada assim de testar …

Tags: Java

23 Apr 07 ICEFaces: Compatibilidade entre versões para que?

Bom, eu retiro o que eu disse neste post.
ICEFaces é um lixo!!!
Escrevi aquele post maravilhado com a facilidade de utilizar o tal do ICEFaces …
e nos ultimos tempos, todos os comentários diziam que o exemplo não funcionava, resolvi então baixar o ICEFaces novamente e testar tudo, ja que fazia muito tempo que eu não o utilizava, e o post foi escrito enquanto eu estava testando opções para um projeto, por tanto, nunca cheguei a utiliza-lo em produção …

Bom, baixei a versão de desenvolvimento 1.6.x e realmente nada funcionou …
baixei a ultima versão estável, e novamente, nada funcionou …

mas como eu tinha certeza absoluta que o exemplo funcionava quando eu postei no blog …
tentei me lembrar qual a versão utilizada no exemplo, e foi a 1.5.0 …
baixei esta versão, e como mágica tudo passou a funcionar …

Agora veja, que lixo de framework …
um exemplo extremamente simples, utiliza 3 componentes, e eu testei eles de forma individual, mas não funciona nem colocando apenas o selectText se não estiver utilizando a versão 1.5.0, se rodar com a 1.5.1 quebra tudo …

Imagina o quanto os clientes destes caras não xingaram eles …

Mas resumindo, atualizei o zip com o exemplo para vocês brincarem um pouquinho, mas a partir de hoje, a minha posição para com o ICEFaces é: NÃO USE, A NÃO SER QUE QUEIRA SE INCOMODAR NO FUTURO!!!

Tags: Java

20 Apr 07 É possivel eliminar a necessidade de configuração para aplicações Java?

Uma das coisas mais chatas hoje para desenvolver aplicações Java é a necessidade de configuração.
E não me entendam errado, eu acho que a possibilidade de configuração é uma coisa excelente …
Acho que estou batendo demais nesta tecla, mas isto não é culpa apenas da plataforma …
Vejam o seguinte exemplo …
Alguem chega para você e diz que tem uma solução para persistência automática dos objetos, mas a aplicação precisa seguir alguns padrões para isto funcionar …

• Todas as classes persistentes precisam estar no mesmo package, ou estender a classe Y
• Todas as classes que serão persistidas precisam ter exatamente o mesmo nome da tabela correspondente
• Os campos da tabela terão os mesmos nomes dos campos
• Todo e qualquer campo que não for de uma classe wraper, collection ou tipo nativo é um relacionamento entre tabelas, e por padrão é do tipo many-to-one
• Todos os campos do tipo collection precisam ter informações genéricas (<TipoContido>) e serão por padrão mapeados para uma coleção do tipo many-to-many
• Para fazer uma coleção one-to-many inversa, basta o tipo destino da coleção ter uma propriedade do tipo da classe origem, quando ouver mais de uma, uma delas precisa ter a palavra “owner” no nome
• As tabelas que irão mapeas as coleções many-to-many terão o nome “classe_propriedade”

Bom, este é só um exemplo, o padrão adotado poderia ser qualquer um …
Qual seria a sua reação para com este framework de persistência?

…
Bom, eu fiz um teste e apresentei esta solução a algumas pessoas e a reação foi exatamente a mesma em todos os casos …
…
Todos disseram algo semelhante com:
Ahh, mas eu não gosto deste padrão, o framework suporta o padrão de nomes XYZ que eu criei para usarmos na empresa?
…
Eu respondia: não, o padrão precisa ser este, caso contrario precisa-se configurar a classe inteira ou classe por classe.
Ahh, então o framework é ruim, não serve, ainda esta muito no inicio, ….
Por que eu quero um framework para configurar automaticamente se eu vou precisar configurar manualmente?

Agora a mesma situação com o Ruby on Rails por exemplo, a grande maior parte dos desenvolvedores RoR que conheço, simplesmente aceita o padrão de nomenclatura do RoR, pelo menos para aplicações novas (claro que este tipo de solução não se encaixa para problemas legados) …

Ou seja, sera que sou só eu que acho que as coisas deveriam ter uma configuração padrão, e só nos obrigar a configurar quando quisermos fugir deste padrão?
e principalmente, se quisermos alterar apenas um pequeno pedaço da aplicação, por exemplo, apenas uma das entidades quer seguir outro nome, só configurar aquela entidade, e não a aplicação toda por causa disto …
Levando isto ao extremo, coisas como a API de Servlets, deveria permitir que frameworks se auto configurassem …

que deveriamos ser obrigados a fazer menos coisas repetidas, e utilizar menos código repetido, por que por exemplo, o web.xml que utilizo é identico em 90% das aplicações …
e sou obrigado a copiar e colar ele sempre …
e no dia que eu descobrir um bug nele, precisarei alterar todas as minhas aplicações …

qual é o problema com facilitar a vida do usuário/desenvolvedor?
Ai alguem vai dizer, mas as ferramentas deveriam fazer isto para você …
Bom, ai temos alguns outros argumentos …
EJBs estão esperando uma ferramenta para facilitar o trabalho desde a versão 1.0
JSF ainda esta esperando uma ferramenta a altura do Visual Studio (este é o caso que chegou mais proximo de conseguir algo na minha opinião, o que estragou foi a mania que temos de “quero fazer do meu jeito”, inclusive foi esta mania que fez eu não gostar da primeira versão do Java Studio Creator, o meu argumento era que a aplicação ficava muito engessada, o que não era realmente tão verdade assim, ele só não deixava eu trabalhar da forma como eu queria, eu não aceitei os padrões dele)
SWING ainda esta esperando uma ferramenta …

E por que as coisas não poderiam simplesmente ser amigáveis ao desenvolvedor, e permitir a utilização de ferramentas também?
(Alguem lembra do Delphi? É perfeitamente possível e fácil criar formulários 100% via código na mão, e mesmo assim tem um editor de formulários espetacular … )

e por ultimo …
Estas ferramentas não são criadas simplesmente por que não é possível, ou por que não aceitamos elas por estarmos mal acostumados?
Sera que nenhuma empresa investe em criar estas ferramentas por que desenvolvedores java estão tão acostumados a passar trabalho que gostam disto? mesmo que em algum nível inconsciente?

PS.: acho que escrevi praticamente a mesma coisa ja, só não lembro se foi aqui no blog ou em algum forum por ai

Tags: Java