What I have seen in many forums, and me myself was able to experience, was that if you are planning on use ICEfaces 2.0 you need JBoss 6.0. ICESoft has provided a NetBeans 6.9 community plugin that supports ICEfaces 2.0 and the problem is NetBeans 6.9 does not support JBoss 6.0.

Now you have to choose between wait until there is a NetBeans 7.0 available or build and manage your project manually. Since I didn’t want neither I decided to study NetBeans source code to see where it mentions JBoss 6.0.

I have found one of the many forums some tips about a patch that could be installed in order to make it start JBoss 6 correctly, not only it is really complicated to apply it, it is not a complete solution. This is because before starting JBoss 6 it must be correctly recognized by NetBeans 6.9 and that is the point. Using the information that is on the NetBeans bug list I found where the servers are installed, but now the problem was, what to do? That was when it occurred me that I could try checking NetBeans 7.0 source code to see what was different.

I’ve found out that I needed to change the server installation wizard and I used the “diff to” tool from NetBeans to find the files that were different the list is:

• src/org/netbeans/modules/j2ee/jboss4/ide/ui/JBPluginUtils.java
• src/org/netbeans/modules/j2ee/jboss4/ide/ui/JBInstantiantingIterator.java
• src/org/netbeans/modules/j2ee/jboss4/ide/JBLogWriter.java
• src/org/netbeans/modules/j2ee/jboss4/util/JBProperties.java

I was kind of naive to think that it would be enough however when installed I was able only to install JBoss 6 as a server but couldn’t create projects compatible with JEE6, only JEE5 was available.

Up until this point we are talking about 8 hours of stone breaking

The second part was a little more complicated because I didn’t know where to start, so I started searching the folders for any class that could contain a reference to JEE6 that is when I found that the class responsible for JBoss EE configurations was:

• src/org/netbeans/modules/j2ee/jboss4/ide/JBJ2eePlatformFactory.java

Cool! But, how could I get it to work? For the source code correction I went through the same process of “diffing” them, but the project simply stopped compiling!

What I found was that the whole NetBeans internal structured changed and this was complicated the figure out. I found that I would need to copy a new abstract class called:

• j2eeserver/src/org/netbeans/modules/j2ee/deployment/plugins/spi/J2eePlatformImpl2.java

and this wasn’t for the NetBeans JBoss support structure, this needed to be on the core libraries. But still no compilation, the project.xml needed to include a reference to the library, this was a minor problem

After the whole compilation process was through I thought it would be easier to simply copy the new jar files to my NetBeans 6.9.1 installation under the enterprise/modules folder and it worked fine!

The next step was to test everything both with and without ICEfaces 2.0, everything went fine using EJB injections, and even using the  debug feature when starting JBoss 6 under NetBeans.

And that were more 8 hours of broken stone carrying

So here is a zip file that contains the libraries ready for use. You are free to use it but I offer no warranties, so use it at your own risk. You have to unzip it under the NetBeans 6.9 or 6.9.1 folder and beware that when creating JSF/ICEfaces projects with JBoss 6 DO NOT include the jsf-api and jsf-impl into the war/ear file because it will conflict with the JBoss 6 provided libraries.

netbeans-6.9-JBoss6

If you think that all this work will help you please donate and help more solutions come to life!

Mas é exatamente disso que os testes de usabilidade tratam, e no final das contas, temos mais é que testar isso tudo mesmo! Eu acho que quanto mais fácil se tornou desenvolver os sistemas, mais preguiçosos ficamos. Explico. Fácil de desenvolver porque hoje temos ferramentas de geração de código (que não existiam até bem pouco tempo) baseadas em padrões de projeto (que não estavam documentados até bem pouco tempo) que nos permitem simplesmente esquecer que certas partes precisam ser feitas. Muitas vezes tudo que precisamos fazer é introduzir pequenos detalhes específicos no código gerado, mas na maioria dos casos nem isso! Ficamos preguiçosos porque os sistemas cresceram, são agora corporativos, é muito menor a demanda de pequenas empresas por seus próprios softwares, com isso o analista que sai da faculdade demora a ter, se é que vai ter, contato direto com o cliente. Os analistas passam a ter um ponto focal centralizado a quem se reportam e acho que isso mascara a responsabilidade levando a uma negligência involuntária.

Antes que eu receba vários ataques de analistas raivosos, não estou aqui falando que todo analista de sistemas (e neste caso estou considerando a dualidade analista/programador) sejam negligentes. Embora eu já tenha trabalhado com muitos que eram realmente negligentes, estou falando aqui de uma negligência involuntária, é mais uma coisa de não fazer porque a percepção é de que o software é para uso próprio e poderemos conversar com o usuário e explicar.

Mesmo que o software seja para uso da própria empresa deve ser desenvolvido com todo o cuidado. Você pode ler mais sobre as minhas impressões sobre análise em:

• Como se faz análise
• Antes de resolver, defina o problema
• Artesanato de Software

Mas agora de volta aos testes de usabilidade. Um problema que temos com os sistemas corporativos é que são muito difíceis de testar pelo alto grau de dependência entre as partes, dessa forma, os testes unitários são quase testes de integração. Uma alternativa é fazer os testes unitários das camadas mais básicas de forma a garantir que estas estão funcionando de forma que os testes das camadas superiores possam se basear nessas camadas, mas se fizermos isso quebramos a possibilidade de paralelizar nossa equipe já que não haverão módulos básicos suficientes para todos. O que acaba ocorrendo é que as pessoas codificam antes de criar seus testes (acredite o Test Driven Development funciona!) e acabam por nunca mais fazer os testes.

Além disso os sistemas corporativos têm uma tendência forte a serem baseados em arquitetura Web ou SOA precisando estar instalados em um servidor de aplicação para executar, o problema disso é que a fórmula:

(a implantação do sistema em um servidor + iniciar o servidor de aplicação) * (obter referências aos componentes a serem testados + executar os testes)

Não é facilmente incluída nos scripts de testes unitários. O que estou pensando em adotar é um esquema de testes semiautomatizado, ou seja, a parte de iniciar o servidor e implantar a aplicação é feita manualmente, a parte de obter referências e executar testes é feita com JUnit.  Até existe um framework JSFUnit, mas infelizmente ele tem uns problemas com o ICEfaces, eu até achei o ponto onde é o problema (depois de baixar o código fonte do JSFUnit e do ICEFaces dos repositórios e gastar umas 4 horas nisso direto), mas precisa de uma modificação no código que ainda não tive tempo de implementar e testar. Embora esta seja uma parte importante, ainda assim não testaria todo o sistema, porque não resolveria a parte dos EJBs e depois de testar com EJBUnit (e mais alguns vários) chegamos a conclusão que não existe um suporte efetivo para essa camada.

Um pouco dessa dificuldade vem do fato que os frameworks *Unit são ferramentas independentes, se a Oracle/Sun adotassem o *Unit como padrão da implementação do Java isso seria incrível para os desenvolvedores, isto porque toda vez que saísse uma nova versão da plataforma e suas especificações já teríamos uma ferramenta de testes para usar.

Estou realmente achando que essa coisa de testes unitários semiautomáticos pode dar certo para a camada EJB.

Uma outra alternativa mais radical (e que na verdade eu gosto muito) é fazer o sistema todo isolado de tecnologias específicas tal como EJB, ou seja, as regras de negócio ficam em classes puramente Java, também conhecidos como POJO – Plain Old Java Objects – algo que em português seria (livremente) traduzido para Bom e Velho Objeto Java. Isto funciona porque os POJOs podem ser facilmente testados com JUnit básico, e se você usar o EJB apenas para envolver os POJOs então você garante que as regras de negócio estão sendo testadas o que já é um grande alívio. Mas porque então não tem muita gente fazendo isso?

Para separar as regras de negócio você terá mais uma camada, mais um nível de indireção e consequentemente mais classes para gerenciar. Acredito que esta seja a maior barreira para se adotar essa prática, mas eu vou criar um sistema de testes (digo sistema, porque para testar esse tipo de coisa não adianta criar uma classezinha de teste) para avaliar o impacto de se criar essa camada extra.

Outro fator é que muitas vezes as regras de negócio têm dependências de dados que precisam ser supridas, se você conseguir prever todas as necessidades de acesso a banco de dados por exemplo e executar isso antes de chamar o método fica mais fácil de tratar, mas as vezes precisamos fazer uma busca em banco no meio de um processamento de regra de negócio. Aí começa o dilema, porque se você usa JPA com EJB, então terá uma dependência do servidor de aplicação para resolver isso e quebramos a automatização do teste de novo. É claro que você pode usar Mock Objects, uma técnica de fornecer objetos que fingem ser os que realmente precisamos para efeitos de teste, mas ainda assim você terá uma proliferação de classes muito grande.

Assim que eu tiver resultados vou colocar aqui.

Pois é, há algum tempo eu coloquei aqui um post sobre o framework ICEFaces, uma implementação do Java Server Faces. Eu relatei a minha experiência com o framework, que aliás tem sido muito boa. Esse post estava concorrendo no concurso da ICESoft e eis que hoje chegou a minha camiseta ! Aqui o link para a página de ganhadores.

Quando vamos atualizar uma biblioteca, um produto, um sistema, precisamos antes fazer um teste nas funcionalidades para garantir que tudo vai ficar correto. Exemplo, o ICEFaces 1.8.x funciona corretamente com o Netbeans 6.7, mas devido as mudanças estruturais da versão 6.8 não havia plug-in nem suporte, ou seja, migrou vai ter que codificar como se fosse um editor de texto simples, então enquanto não fizer todos os testes não dá para atualizar porque a produção de sistemas depende desses fatores para ser produtiva.

Outro exemplo, a versão ICEFaces 2.0 já está disponível, mas não sei se tudo no sistema funciona com essa nova versão, então não dá para simplesmente instalar a versão nova, é necessário, entre outras coisas, ler os comentários do release feitos pelo fornecedor para entender o impacto da mudança no seu sistema. Ah sim, e saber se a versão nova vai funcionar (ou quando vai funcionar) com a sua IDE.

Já vinha planejando escrever sobre ICEFaces (http://www.icefaces.org) há algum tempo, mas estava esperando experimentar mais com a biblioteca. Há algum tempo através me solicitaram buscar uma solução para desenvolvimento de interfaces de usuário para web que fosse ágil e fácil de programar e, se possível, que permitisse edição visual. Com essas características eu pensei no projeto (agora extinto) Woodstock da parceria Sun/Netbeans que permitia a edição visual de telas baseado em tecnologia JSF, quando comecei a ler descobri que a Sun estava abandonando o projeto e passaria a apoiar a implementação ICEFaces, da ICESoft, que também provia uma forma visual de editar as páginas e estaria incorporando a compatibilidade com projetos Woodstock.

Na época o Netbeans estava na versão 6.5.1, fiquei animado e experimentei a ferramenta, fácil de usar, fácil de integrar, mas logo em seguida o Netbeans mudou a estrutura do núcleo e o resultado foi que cortaram o suporte a edição visual, mas a Sun continuou apoiando a implementação ICEFaces, embora a Sun forneça uma implementação de referência de JSF, existem por aí outras opções as mais expressivas são MyFaces (Apache), RichFaces (JBoss) e ICEFaces (ICESoft.)

A primeira coisa que me levou a considerar a implementação ICEFaces foi a questão de a própria Sun apoiar esse desenvolvimento, a partir disso eu comecei a procurar os componentes, na versão 1.8.2, que é a que estamos usando em projeto, existem mais de 54 componentes gratuitos, isto porque a ICESoft oferece um modelo de licenciamento para empresas que dá acesso a alguns outros componentes, além disso a parte de tutorial e exemplos é muito fácil de entender e usar.

Ao longo do projeto fomos descobrindo outras funcionalidades o que só confirmou a escolha acertada que fizemos em usar o ICEFaces, a parte de layout e de panéis e muito funcional, a demonstração dos componentes pode ser encontrada em ICEFaces Component Showcase e como era de se esperar o site deles é todo feito em ICEFaces. Outra característica interessante é o uso intenso de ajax de forma totalmente transparente, o usuário não precisa se preocupar, além disso os componentes funcionam em diversos browsers sem que seja necessário escrever nada de javascript.

O fórum também é bem ativo é costuma ser fácil de conseguir as respostas para os problemas mais comuns que temos, utilizamos o Facelets junto com o ICEFaces, sendo que já vem uma biblioteca de integração fácil de usar, uma ressalva importante é que foi muito mais fácil de fazer funcionar no Glassfish do que no JBoss, isto porque no JBoss já existem as bibliotecas do RichFaces então torna-se necessário indicar no web.xml que estamos fornecendo as bibliotecas de implementação. Um outro problema é que o JBoss (5.1) não consegue injetar dependências (tipo EJB3) em managed beans, apenas em classes que foram declaradas no web.xml tais como Servlets e Listeners, isso é uma coisa realmente incomoda (até porque no Glassfish isso funciona facilmente.)

Finalmente a única pendência que está me incomodando fortemente é que não temos uma solução de testes unitários funcionando corretamente, comecei a testar o JSFUnit desenvolvido pela JBoss, mas ele entra em loop durante o processamento, embora seja possível testar alguns componentes de tela eu estava mais interessado em testar os managed beans e isso ainda não é possível, está na minha lista de trabalho recompilar o JSFUnit com algumas modificações, mas isso está longe do topo de prioridades.

No total é uma ferramenta muito boa e fácil de usar, recomendo fortemente. Em breve vou começar as experiências com a versão 2.0 que implementa a especificação JSF 2.