Marcos Sousa’s Blog

Faz um tempinho que não escrevo nada por aqui. Além de projetos críticos que estou participando, estava muito envolvido na leitura de dois livros relacionados a Agile, que os comentarei em breve, e também estou escrevendo uma série de artigos para a revista Java Magazine, o primeiro sai na edição 72. A partir de agora devo publicar pelo menos uns 2 post mensais.

O Seam Remoting oferece uma forma conveniente de acessar componentes backing beans via AJAX. Com uma simples anotação é possível chamar ações, intanciar objeto e etc. Porém este recurso é uma maneira limitada de acessar o contexto dos componentes e requer uma certa atenção de nós desenvolvedores. Pessoalmente, pude presenciar soluções fantásticas usando remoting e mas algumas implementações desastrosas. Fica a dica: use o remoting apenas quando os componentes AJAX existentes não solucionam um dado problema.

Por padrão, uma requisição AJAX via Seam Remoting não possui controle de transações e o contexto JSF não é criado. Para ambos os casos é possível habilitá-los. O controle de transações é mais simples, basta adicionar a anotação @Transactional com o tipo REQUIRED. Veja o exemplo:

@WebRemote @Transactional(TransactionPropagationType.REQUIRED)
public void updateUserProfile(Profile profile) {
entityManager.merge(profile);
}

Criar o contexto JSF exige algo um pouco mais avançado. Antes de iniciar a execução das ações, o contexto JSF deve ser criado, e para a sua criação é preciso o HttpServletRequest e o HttpServletResponse. Uma forma seria criando um filtro, mas acredito que não é uma boa solução. O Seam possui um recurso de ExecutionHandler que permite executar determinadas operações em requisições Remoting antes executar a ação. Este recurso usa o padrão Observer, onde o primeiro passo é criar o observer, ele precisa de implementar a interface ExecutionHandler:

public class RemotingFacesContextHandler extends ExecutionHandler {

private ServletContext servletContext;

protected FacesContext getFacesContext(HttpServletRequest request,
HttpServletResponse response) {

FacesContext facesContext = FacesContext.getCurrentInstance();

if (facesContext == null) {
FacesContextFactory contextFactory = (FacesContextFactory) FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
LifecycleFactory lifecycleFactory = (LifecycleFactory) FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
facesContext = contextFactory.getFacesContext(servletContext,request, response, lifecycle);
}

return facesContext;
}
@Override
public void handle(HttpServletRequest request, HttpServletResponse response)
throws Exception {
getFacesContext(request, response);
super.handle(request, response);
}
@Override
public void setServletContext(ServletContext ctx) {
this.servletContext = ctx;
super.setServletContext(ctx);
}
}

O método handle chama o método getFacesContext que é responsável por iniciar o contexto. A inicialização do FacesContext é feita por meio do método getFacesContext da classe FacesContextFactory. Além do contexto servlet, do request e do response, é necessário informar o ciclo de vida JSF.O Ciclo de vida é criado por meio da classe LifecycleFactory.

Uma vez criado o observer, basta registrá-lo. Uma das várias alternativas é registrá-lo após a inicialização usando a anotação @Observe:

@Name("registerHandler")
public class RegisterFacesContextHandler {
private static final String REQUEST_PATH_EXECUTE = "/execute";

@Observer("org.jboss.seam.postInitialization")
public void initHandler() {
RequestHandlerFactory.getInstance().registerHandler(REQUEST_PATH_EXECUTE, new RemotingFacesContextHandler());

}

}

Após inicializado o Seam (org.jboss.seam.postInitialization) o observer é registrado. Com isto você pode chamar FacesContext.getCurrentInstance() que não receberá aquele NullPointerException indesejado.

Fazendo alguns testes com o Seam acabei descobrindo uma falha de compatibilidade do Seam Generator da versão 2.1 com as versões anteriores. O problema reside nos filtros que são criados nas páginas de listagens.

Nas versões anteriores, o componente para as páginas de listagens sobrescreviam os métodos:
- getEjbql: Consulta EJB QL usada para a listagem.
- getMaxResults: Define a quantidade de registros a serem retornados pela listagem.
- getRestrictions: Retorna lista de restrições a serem adicionadas a consulta.

Porém na versão 2.1 estes métodos deixaram de ser usados na geração do código. O problema é que o método getRestrictions teve o retorno aterado. Nas versões anteriores ele retornava uma lista de Strings, já na versão 2.1 o tipo de retorno foi alterado para uma lista de ValueExpression.

Com isto um código gerado na versão na versão 2.0.3, por exemplo, gera ClassCastException ao tentar converter String em ValueExpression. Solução? Atualizar o código, veja o antes e o depois:

@Name("userList")
public class UserList extends EntityQuery {

private static final String[] RESTRICTIONS = {
"lower(user.login) like concat(lower(#{userList.user.login}),'%')",
"lower(user.name) like concat(lower(#{userList.user.name}),'%')"};

private final User user = new User();
@Override
public String getEjbql() {
return "select user from User user";
}

@Override
public Integer getMaxResults() {
return 25;
}

public User getUser() {
return user;
}

@Override
public List<string> getRestrictions() {
return Arrays.asList(RESTRICTIONS);
}

}

A versão 2.1 o código gerado é algo semelhante a:

@Name("userList")
public class UserList extends EntityQuery<user> {

private static final String EJBQL = "select user from User user";

private static final String[] RESTRICTIONS = {
"lower(user.login) like concat(lower(#{userList.user.login}),'%')",
"lower(user.name) like concat(lower(#{userList.user.name}),'%')"};

private final User user = new User();

public UserList() {
setRestrictionExpressionStrings(Arrays.asList(RESTRICTIONS));
setMaxResults(25);
setEjbql(EJBQL);
}

public User getUser() {
return user;
}
}

Até que seja corrigido o problema fica a dica.

Desenvolver aplicações com URL amigáveis em projetos JSF não é uma tarefa fácil. Porém ao utilizar o Seam, esta tarefa é muito facilitada. A versão 2.1 traz a integração nativa com o URLRewrite, simplicando ainda mais o desenvolvimento.

Meu objetivo neste post é mostrar as diferenças para implementação da mesma funcionalidade na versão 2.0 e a versão 2.1. Até a versão 2.1 era necessario (sem acento mesmo, dentro da reforma ortográfica) a criação de um Adapter. Vejamos como era feito, há até uma vídeo aula publicada sobre o assunto, primeiro vamos ao Adapter, necessário para fazer com que o URLRewriter resolva as URLs:

@Startup
@Scope(ScopeType.APPLICATION)
@Name("seamUrlRewriterFilter")
@BypassInterceptors
@Filter(within="org.jboss.seam.web.ajax4jsfFilter")
@Install(classDependencies="org.tuckey.web.filters.urlrewrite.UrlRewriteFilter",
precedence=Install.APPLICATION)
public class SeamUrlRewriterFilter extends AbstractFilter {

private UrlRewriteFilter urlRewriteFilter;
private Map initParameters;

public void init(FilterConfig filterConfig) throws ServletException {
urlRewriteFilter = new UrlRewriteFilter();
urlRewriteFilter.init(new FilterConfigWrapper(filterConfig, getInitParameters()));
}

public Map getInitParameters() {
return initParameters;
}

public void setInitParameters(Map initParameters) {
this.initParameters = initParameters;
}

public void doFilter(ServletRequest arg0, ServletResponse arg1,
FilterChain arg2) throws IOException, ServletException {
urlRewriteFilter.doFilter(arg0, arg1, arg2);
}

private class FilterConfigWrapper implements FilterConfig {

private FilterConfig delegate;
private Map parameters;

public FilterConfigWrapper(FilterConfig config, Map parameters) {
this.delegate = config;
this.parameters = parameters;
}

public String getFilterName() {
return delegate.getFilterName();
}

public String getInitParameter(String arg0) {
if (parameters.containsKey(arg0)) {
return (String) parameters.get(arg0);
} else {
return (String) delegate.getInitParameter(arg0);
}
}

public Enumeration getInitParameterNames() {
Enumeration[] enumerations = {delegate.getInitParameterNames(),
Collections.enumeration(parameters.entrySet())};
return new EnumerationEnumeration(enumerations);
}

public ServletContext getServletContext() {
return delegate.getServletContext();
}
}
}

Você pode estar pensando: porque não declarar o filtro diretamente no web.xml? Precisamos garantir que ele seja executado após filtro do RichFaces, através da anotação @Filter(within=”org.jboss.seam.web.ajax4jsfFilter”). Também é importante que este filtro esteja dentro do contexto seam. Para que este Adapter funcione adequadamente,  devemos registrá-lo no arquivo component.xml para que as URL’s sejam interpretadas.

<component name="seamUrlRewriterFilter" class="jm.seamtest.core.SeamUrlRewriterFilter" precedence="30">
<property name="initParameters">
<key>logLevel</key>
<value>DEBUG</value>
<key>statusEnabled</key>
<value>false</value>
</property>
</component>

Já na versão 2.1, todas estas configurações não são mais necessarias. Basta adicionar esta tag no arquivo de configurações do seam, components.xml:

<web :rewrite-filter view-mapping="*.seam" />

Vamos imaginar como exemplo de URL amigável, a url usada neste blog para visualização de posts: /ano/mes/dia/titulo-uuid. Vamos analisar como era as configurações nas versões anteriores, a configuração do padrão de url era realizado diretamente no arquivo de configurações nativo do URLRewrite:

<rule enabled="true">
<from casesensitive="true">^/([0-9]{4})/([0-9]{2})/([0-9]{2})/([A-Z0-9]+[A-Za-z0-9]*)?$</from>
<to>/post/showpost.seam?ano=$1&mes=$2&dia=$3&tituloUUID=$4</to>
</rule>

O URLRewrite, exige do desenvolvedor conhecimentos de expressões regulares. Além do mapeamento da URL, é necessário vincular os parâmetros passados pela URL, uma das formas é usando Page Actions:

<page view-id="/post/showpost.xhtml">
<param name="ano" value="#{viewPostBean.ano}" />
<param name="mes" value="#{viewPostBean.mes}" />
<param name="dia" value="#{viewPostBean.dia}" />
<param name="tituloUUID" value="#{viewPostBean.tituloUuid}" />
<action execute="#{viewPostBean.show}" />
</page>

Na versão 2.1, não é mais necessária a configuração nativa, tudo que precisamos é de uma simples tag para mapear a url dentro da Page Action.

<page view-id="/post/showpost.xhtml">
<rewrite pattern="/{ano}/{mes}/{dia}/{tituloUUID}"/>
<param name="ano" value="#{viewPostBean.ano}" />
<param name="mes" value="#{viewPostBean.mes}" />
<param name="dia" value="#{viewPostBean.dia}" />
<param name="tituloUUID" value="#{viewPostBean.tituloUuid}" />
<action execute="#{viewPostBean.show}" />
</page>

O padrao de URL “/{ano}/{mes}/{dia}/{tituloUUID}” pode é traduzido em  /post/showpost.xhtml?ano=2009&mes=03&dia=16&tituloUUID=url-amigavel. Neste caso todas as variáveis entre chaves são transformadas em parâmetros HTTP. Simples não?