idi-language: #00FF">Migrando aplicações Struts 1.x para o Struts2
Aprenda na prática como migrar suas aplicações de forma simples para a nova versão do Struts
No JavaOne de 2005, alguns desenvolvedores do Struts e do Apache Beehive reuniram-se para discutir o futuro do Struts. Então, eles criaram a Struts Ti Proposal (veja Nota 1): uma proposta que definia um framework que caminhasse junto às boas idéias que estavam sendo desenvolvidas pela comunidade do framework. O grande problema era que o código do Struts 1 não suportava melhorias drásticas e suas principais funcionalidades eram bem limitadas, particularmente faltando suporte a Ajax, desenvolvimento ágil e estensibilidade.
|
Nota 1. Struts Ti Proposal |
|
Struts Ti é um framework para desenvolvimento de aplicações web que permite aos desenvolvedores acessarem o ambiente de servlets e portlets de maneira simples. Ele atende a um nicho de aplicações web que não necessitam da complexidade adicional de componentes do lado do servidor e configurações verbosas. O Struts Ti é construído baseado no Struts 1.x, reimplementa o framework para prover a nova geração do Struts Ti e combina a simplicidade do Ruby On Rails e Nano Web, o refinamento do WebWork 2, o sistema de fluxo de página do Beehive e as lições aprendidas com o Struts 1.x. |
Na mesma edição do JavaOne, Don Brown (Struts) e Jason Carreira (WebWork) reuniram-se para discutir como poderiam trabalhar melhor juntos. Eles decidiram trabalhar diretamente em cima do WebWork 2 no tempo sobressalente. Nesse mesmo espaço de tempo, Patrick Lightbody e Jason Carreira (WebWork), Ted Husted e Don Brown (Struts) e Keith Donald (Spring WebFlow) tiveram a idéia de juntar os desenvolvedores do Struts, Spring WebFlow, WebWork e Beehive para conversarem sobre a possibilidade de combinar esforços em um único framework. Infelizmente essa idéia não pôde ser viabilizada porque o Beehive e o Spring WebFlow eram incapazes de fazer progresso fundindo suas funcionalidades.
Pretendendo não jogar fora todo o esforço, Ted Husted e Don Brown iniciaram conversas com Patrick e Jason sobre como poderiam trabalhar melhor juntos. Patrick casualmente sugeriu a idéia de uma junção entre Struts e WebWork, que foi aceita por todos. Iniciaram então o processo de incubação da Apache para o WebWork 2. Nesse tempo, o Struts estava servindo de guarda-chuva para diversos projetos web, incluindo o Struts Shale: um framework web baseadoem JSF. Infelizmente esses subprojetos estavam confundindo os desenvolvedores e a comunidade de usuários, acostumados com o nome “Struts” referenciando um único framework. Depois de uma tentativa de unificar os frameworks, os desenvolvedores do Struts Shale sentiram a necessidade de migrar um projeto próprio e não ser mais um subprojeto do Struts. A partir desse momento nasceu o Struts 2.
Em 11 de janeiro de 2006 o time de desenvolvimento do WebWork anunciou o lançamento da versão 2.2 (apresentada nas edições 11 e 12 da WebMobile). Essa versão possuía muitas novidades, incluindo: suporte completo ao Java 5, validação com Ajax, suporte nativo ao Pico Container e Spring Framework, etc. Essa versão ficou marcada na história do WebWork, pois seria a última versão sobre o nome WebWork e OpenSymphony (veja Nota 2)
|
Nota 2. OpenSymphony |
|
O OpenSymphony é um grupo open source que se dedica a hospedar projetos Java EE. Muitos projetos hospedados pela OpenSymphony são bastante famosos na comunidade de desenvolvimento Java, entre eles podemos citar o WebWork, SiteMesh e Quartz. |
Hoje o WebWork continua liberando novos patches e certamente continuará liberando até que o Struts 2 atinja a versão final, mas todo o novo desenvolvimento será feito sobre o código do Struts 2. Há muitos desenvolvedores entusiasmados trabalhando no desenvolvimento do Struts 2, tentando combinar a estabilidade do Struts 1.x com a arquitetura elegante do WebWork 2. Desde a incubação inicial na Apache, foram adicionadas ao código do Struts 2 novas funcionalidades incluindo plug-ins, uma nova API e tags ajax melhoradas. Como prometido na Struts Ti Proposal, muitas novidades estão por vir.
A seguir veremos em detalhes o funcionamento do Struts 2.
Arquitetura
A Figura 1 descreve a arquitetura do framework. No diagrama, a requisição inicial parte do servlet container, que pode ser o TomCat ou Jetty, por exemplo. A requisição é passada através de uma cadeia de filtros. A cadeia inclui um filtro opcional chamado ActionContextCleanUp, que é útil para integração com outros frameworks, como o SiteMesh. Possui também o filtro FilterDispatcher que consulta o ActionMapper para determinar se a requisição deve invocar uma Action.
Figura 1. Funcionamento do Struts 2
O ActionMapper provê um mapeamento entre requisições HTTP e invocações de actions. Dada uma requisição HTTP, o ActionMapper deve retornar NULL se nenhuma action for invocada ou deve retornar um ActionMapper que descreve uma invocação de uma action para o framework tentar executar. Se o ActionMapper determinar que uma action deve ser invocada, o filtro FilterDispatcher delega o controle para o ActionProxy.
O ActionProxy consulta os arquivos de configuração do framework. Feito isto, o ActionProxy cria uma ActionInvocation, que é responsável pela implementação do padrão de projeto Command. No ActionInvocation ainda é possível invocar qualquer Interceptor. Quando a action retornar, o ActionInvocation é responsável por procurar um result associado com o result mapeado no arquivo de configuração do Struts (struts.xml). O resultado é então executado. Freqüentemente o resultado envolve um template escrito em JSP ou FreeMarker para ser renderizada.
Guia de migração para o Struts 2
A seguir, veremos como é realizada a migração de aplicações construídas com Struts 1.x para o Struts 2. Para realizar a migração, é preciso saber quais as diferenças entre as versões. A ...
