Resumos das palestras do TDC 2009

Seguem resumos das palestras dos keynotes no The Developer's Conference 2009 - Floripa [1] ministradas no dia 9 de novembro.

Tendências em Java EE: Como serão os próximos 5 anos - Rod Johnson

O criador do Spring [2], um dos mais populares frameworks em Java, apresentou nesta palestra suas previsões para o futuro da tecnologia da informação como um todo. Nessa linha, afirmou que "estamos a ponto de presenciar a maior ruptura em TI desde o declínio do mainframe", impulsionada por forças como Cloud Computing, Lei de Moore e o fato de os custos estarem se voltando para as pessoas em contraposição ao hardware.

Disse também que sistemas gerenciadores de bancos de dados relacionais (SGBDRs) não irão embora, e ao invés disso haverá grande ascensão da chamada "persistência poliglota", onde haverão diferentes meios de se armazenar os dados. (Aqui entra a JPA!)

Sobre a computação em nuvem, afirmou que ela está mais próxima que SOA e que possui as seguintes vantagens características: ser abstrata, integrada e opinativa, dinamicamente escalável e consumida como um serviço, além de inevitável devido a questões econômico-ambientais. E com isso, disse que nós desenvolvedores nos tornaremos mais poderosos! :) Precisaremos fornecer APIs direcionadas para a nuvem...

Com relação aos frameworks, iniciou com a frase "Frameworks can't be too disruptive!", alegando que o código aberto possibilitou a criação de excelentes soluções de software, mas por outro lado fez do Java uma plataforma confusa para os iniciantes.

Finalizou dizendo que nessa era de desordem a abstração será mais importante do que nunca, citando como possíveis gerenciadoras para esse caos no software as seguintes soluções: Grails, Spring, Roo e Rails, além de especificações como a JPA.


Java EE 6 - Uma grande evolução - Mike Keith

O Mike é o líder de importantes especificações do Java, tal como EJB 3 e JPA, e iniciou esta palestra apresentando os objetivos e destaques para a esperada versão 6 do Java EE [3], especialmente JSF 2.0, Servlet 3.0, EJB 3.1 e JPA 2.0.

Em seguida resumiu cada uma das novas funcionalidades: Java Profiles, JNDI Namespaces, Data Source Definition, novas anotações para Web (ex: @WebServlet, @ServletFilter, @WebServletContextListener), Web Fragments, Async Processing (mesmo para session beans!). Além disso, para o EJB 3.1 teremos: interfaces opcionais, singleton, concorrência, timer estilo cron, EJB lite, contêiner embutido e novas regras de empacotamento.

A JPA 2.0 terá cache compartilhado, melhorias na JPQL e a inclusão de uma API de Criteria. Os Managed Beans substituirão os MBs atuais do JSF e haverão anotações para injeção comuns a JSE e JEE, além do início de sua padronização. Os WebBeans serão contemplados pela CDI 1.0, a qual basicamente visará gerenciar objetos injetáveis ligados a contextos do ciclo de vida, possuindo anotações como @Inject, @Qualifier, @Scope, @Named e @Singleton.

Outra questão importante refere-se ao processo de limpeza, em que determinadas tecnologias tornaram-se obsoletas e entrarão no estágio de poda (pruning stage). Entre elas citou JAX-RPC, EJB Entity Beans, JAXR e JSR-88 Deployment. Os fornecedores não serão obrigados a implementá-las em releases futuras.

Por fim, a notícia que mais aguardávamos, a data do lançamento. Mike disse que os grupos de experts das JSR praticamente já concluíram seus trabalhos e que a Java EE 6 será liberada no dia 10 de dezembro!


JSF 2.0: Uma Abordagem Completa - Ed Burns



Ed iniciou a palestra fazendo uma pequena introdução sobre a tecnologia JavaServer Faces a fim de balizar o conhecimento do público. Apresentou o ciclo de vida no processamento de requisições do JSF e as funcionalidades desejadas (conversão e validação de dados, fluxo de páginas, integração com banco de dados, desempenho, segurança, etc).

Enfatizando os 4 pilares do JSF 2.0 (visão, interação com o modelo, navegação e ciclo de vida), destacou que as visões passarão a ser páginas Facelets, haverá a anotação @ManagedBean, e que o JSP será depreciado.

A Expression Language será mais poderosa, e na navegação de páginas o uso de XMLs será opcional, devido à nova navegação implícita, altamente dinâmica e especialmente útil com os novos objetos do tipo "flash". Com relação ao ciclo de vida, haverá um excelente suporte para o uso de Ajax, além do advento dos System Events, finos ouvintes dos eventos do ciclo.


Spring Roo - Rod Johnson

Em substituição ao Chris Schalk da Google, Rod fez uma palestra prática totalmente sem slides apresentando uma nova solução da SpringSource: o Spring Roo [5].

Trata-se de um gerador de código em Java que como qualquer do gênero visa impulsionar a produtividade do desenvolvimento. Achei muito semelhante ao Ruby on Rails: um prompt de comando (shell) que executa diversas tarefas, especialmente a criação automática de inúmeros arquivos e o fornecimento de um servidor Web simples para os testes. Funciona até auto-completion no estilo bash!

A instalação do Roo é extremamente simples, mas ele exige que tenhamos o seguinte ambiente: Eclipse IDE com plugins WTP e AJDT. Isso mesmo, o Spring Roo usa extensivamente o AspectJ! São criados arquivos ".aj" a fim de incluir funcionalidade as novas classes.

Outras características importantes foram a criação automática de testes unitários, o fato de o projeto ser gerenciado pelo Maven (são criados diversos arquivos "pom.xml") e a persistência ser manipulada através de JPA.

A mágica do Roo acontece durante o gerenciamento das entidades. Por exemplo, os métodos persist() e findAll() são inseridos em cada entidade através de injeção de aspectos! Achei um tanto bizarro, mas não deixa de ser uma possibilidade interessante. As entidades não precisam declarar métodos getters e setters e nem toString() customizado, pois, novamente, aspectos fazem isso..!

Eis um exemplo de classe criada no Roo:

@Entity
@RooJavaBean
@RooToString
@RooEntity
public class Restaurant {

   private String name;

}

Tal como no Rails, podemos criar com uma agilidade e rapidez descomunal uma aplicação completa incluindo scaffold (i.e. o CRUD), testes unitários, páginas web para apresentação (em JSF!) e toda a configuração da persistência.

Atualmente o Spring Roo está na release candidate 2 e tem previsão de ser liberado no final desse ano. Infelizmente ainda não tem suporte para o NetBeans, devido ao fato de depender do Eclipse AJDT.

Referências:
[1] TDC 2009 Floripa
[2] Spring Framework
[3] Java EE 6 Technologies
[4] JavaServer Faces Technology
[5] Spring Roo

Auction5 sample web application released

I'm very proud to announce that Auction5, a sample web application built under Demoiselle Framework [1] has just been released to the public. Its complete documentation including source codes retrieval and deployment instructions can be found here: [2].

Auction5 is a MVC-structured application that exemplifies an online auction system using Demoiselle Framework and related technologies. Its main goal is to provide a complete transactional application based on JavaServer Faces (JSF 1.2 [3]) and Java Persistence API (JPA 1.0 [4]) specifications.


Moreover, the sample assembles several top computing technologies such as Java EE, Maven, JBoss Application Server, Apache Tomcat, and PostgreSQL DBMS.

Please send me your comments and or suggestions.

References:
[1] Demoiselle Framework
[2] Auction5 Application Sample
[3] JavaServer Faces 1.2
[4] Java Persistence API 1.0

Demoiselle JPA in a Nutshell

One of the greatest new features coming to 1.1 release of Demoiselle Framework [1] is the ability of using JPA [2] (Java Persistence API) in a straightforward manner. JPA specification [3] is a trend in Java development and is often recommended to be used in new applications.

In this article we'll explore the technical steps involved on developing the simplest DAO [4] (Data Access Object) implementation classes with the new JPA support components.

So, what's new in Demoiselle concerning JPA? First of all, there is a new injection aspect towards IDAO [5] interfaces. Basic classes implementing IDAO interface should now simply have an attribute of type EntityManager [6] annotated by @Injection and then with the aid of AspectJ engine and some proxy classes the magic happens!

For instance, consider the following IDepartmentDAO interface in order to manage a Department entity:

public interface IDepartmentDAO extends IDAO<Department> {

    public Department findById(Short id);

}

The respective implementation class DepartmentDAO should have the structure below:

public class DepartmentDAO implements IDepartmentDAO {

    @Injection
    private EntityManager em;

    public Department findById(Short id) {
        return em.find(Department.class, id);
    }

    public boolean exists(Department pojo) {
        return em.contains(pojo);
    }

    public Object insert(Department pojo) {
        em.persist(pojo);
        return pojo;
    }

    public void update(Department pojo) {
        em.merge(pojo);
    }

    public void remove(Department pojo) {
        em.remove(pojo);
    }

}

Simple, isn't it?

EntityManager is the interface used to interact with the persistence context in JPA. A persistence context is a set of entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed. This interface defines the methods that are used to interact with the persistence context. The EntityManager API is used to create and remove persistent entity instances, to find entities by their primary key, and to query over entities.

Within a given unit of work, such as an HTTP request in web applications, a single instance of EntityManager is created and automatically injected on every DAO class that is referenced on that thread. That EntityManager is then closed as the transaction is finished.

Moreover, even outside a complete and robust Java EE application, i.e. without an EJB [3] container, the developer could make easy use of JPA in Demoiselle!

In order to turn it even simpler for the developer, the DAO implementation could still make use of the new JPAGenericDAO [7] support class. Thus, DepartmentDAO could have the following code:

public class DepartmentDAO extends JPAGenericDAO<Department>
    implements IDepartmentDAO {

    public Department findById(Short id) {
        return super.findById(id);
    }

}

In other words, there is no need anymore of storing an EntityManager field and to implement all IDAO methods. That is, there will be almost nothing left to do but customized business rules methods!

If you want to know more about the framework technical details, there will be another article explaining the whole architecture behind the scenes. :D

References:
[1] Demoiselle Framework
[2] The Java Persistence API
[3] EJB 3.0 JPA Specification
[4] Data Access Object
[5] IDAO interface
[6] EntityManager interface
[7] JPAGenericDAO class

Encoding UTF-8 no Tomcat 6.0

Ao utilizar o servidor Apache Tomcat 6.0 [1] para o deploy de aplicações Web em Java utilizando o encoding Unicode (UTF-8) [2] podemos enfrentar pequenos problemas quando existe entrada de dados pelo usuário.

Por exemplo, considere a aplicação a seguir que faz uso de um formulário para o cadastro de categorias de produtos:



A anomalia ocorre durante o processo de envio da requisição HTTP do tipo POST [3]. Veja na imagem a seguir o problema na acentuação resultante do formulário:



Uma possível solução para este problema consiste na criação de um filtro, ou Filter [4], um padrão de projeto da especificação Java EE. A função deste filtro é de interceptar as requisições HTTP e forçar a codificação de caracteres para a que for parametrizada (no exemplo, a UTF-8).

A primeira etapa envolve a criação de uma nova classe na aplicação, cujo nome será EncodingFilter e a qual deverá implementar a interface Filter [5] da especificação Java Servlet. Desta forma, o arquivo EncodingFilter.java terá o seguinte conteúdo:

package com.hsiconsultoria.zabumba.filter;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class EncodingFilter implements Filter {

  private String encoding;

  public void init(FilterConfig config) throws ServletException {
      this.encoding = config.getInitParameter("encoding");
  }

  public void destroy() {
  }

  public void doFilter(ServletRequest request,
          ServletResponse response, FilterChain chain)
      throws IOException, ServletException {
   
      request.setCharacterEncoding(encoding);
   
      chain.doFilter(request, response);
  }

}

Em seguida é preciso indicar a existência desse novo filtro no arquivo WEB-INF/web.xml, também conhecido como Deployment Descriptor [6]. É neste arquivo que o filtro será devidamente configurado para interceptar as requisições HTTP na aplicação Web.

Sendo assim, basta incluir as linhas seguintes no arquivo web.xml:

  
      EncodingFilter
      EncodingFilter
      
          com.hsiconsultoria.zabumba.filter.EncodingFilter
      
      
          filtro para codificação dos caracteres
          encoding
          UTF-8
      
  
  
      EncodingFilter
      /*
  

Para finalizar, é só salvar tudo e reinicializar o Tomcat. Veja na tela abaixo o resultado dessa alteração na aplicação:



Referências:
[1] Apache Tomcat 6.0
[2] Formato UTF-8
[3] HTTP/1.1 Method Definitions
[4] Intercepting Filter Pattern
[5] Interface Filter
[6] Java EE Deployment Descriptors

EJB 3 Developer Guide: Errata on Web Security Sample

Today I was just working on the lab 4 / chapter 12 of this book [1] and then I got stuck into an issue...

The environment used on the tests was GlassFish Application Server v2 and the sample code concerns Web Container Security. It just didn't work as expected...

"lab4:

to run program enter http://localhost:8080/BankService/index.html in browser. http://localhost:8080 is url for web applications as shown by Glassfish on startup. If Glassfish provides port other than 8080 then modify url accordingly.

then enter scott/xyz username/password in login form. servlet menu for adding customer to database is then displayed.

enter ramon/abc username/password in login form. error page is then displayed."

The problem is that the page was never displayed despite using the proper user (i.e. "scott") because security always failed.

After googling for a while, I could realize some missing points in the book packaged sample [2].

Yet I made some small modifications in order to test the application with both users: "scott" (belonging to "bankemployee" group) and "ramon" (belonging to "bankcustomer" group).

So, the idea behind it was to forbid access to a specific servlet ("/addCustomer" address) whenever the user did not belong to "bankemployee" role. Also, to restrict access to "/findCustomer" servlet to both roles.

First of all, I modified the WEB descriptor file, "WEB-INF/web.xml", by adding "/findCustomer" servlet mapping, specifying "/addCustomer" URL pattern in the security constraint and an optional welcome file. Here's the entire code:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
    <servlet>
        <servlet-name>AddCustomerServlet</servlet-name>
        <servlet-class>ch12lab4.AddCustomerServlet</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>FindCustomerServlet</servlet-name>
        <servlet-class>ch12lab4.FindCustomerServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>AddCustomerServlet</servlet-name>
        <url-pattern>/addCustomer</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>FindCustomerServlet</servlet-name>
        <url-pattern>/findCustomer</url-pattern>
    </servlet-mapping>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>bank service most restricted</web-resource-name>
            <url-pattern>/addCustomer</url-pattern>
            <url-pattern>/addCustomer.html</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>bankemployee</role-name>
        </auth-constraint>
    </security-constraint>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>bank service restricted</web-resource-name>
            <url-pattern>/findCustomer</url-pattern>
            <url-pattern>/findCustomer.html</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>bankcustomer</role-name>
            <role-name>bankemployee</role-name>
        </auth-constraint>
    </security-constraint>
    <security-role>
        <role-name>bankemployee</role-name>
    </security-role>
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>file</realm-name>
    </login-config>
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>
</web-app>

The second detail was the creation of a Sun's specific descriptor, "WEB-INF/sun-web.xml", which did not exist in the sample code. The key point here was to map existing groups already specified in the application server's realm file into roles used inside the WEB application. In the current case they share the same names, "bankcustomer" and "bankemployee", on both environments. Here's the new file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC
    "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN"
    "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">
<sun-web-app>
    <context-root>/BankService</context-root>
    <security-role-mapping>
       <role-name>bankcustomer</role-name>
       <group-name>bankcustomer</group-name>
    </security-role-mapping>
    <security-role-mapping>
       <role-name>bankemployee</role-name>
       <group-name>bankemployee</group-name>
    </security-role-mapping>
</sun-web-app>

That's it, it worked at last and I ran the whole book sample codes!

Now I'm gonna take a rest watching "The Hunt for the Red October", which had just finished on the eMule's queue...! :D

References:

[1] Michael Sikora, "EJB 3 Developer Guide", http://www.packtpub.com/developer-guide-for-ejb3/book

[2] Code Download, http://www.packtpub.com/support/book/developer-guide-for-ejb3