Blog do Walter

Geração de métodos de pesquisa para atributos <>

2010-09-25T03:50:00.000-07:00

Acrescentei um novo recurso ao cartucho Spring: a geração automática de métodos de pesquisa quando o atributo da entidade é único. Para todos os atributos marcados como únicos ( <<Unique>> ) da sua entidade, será gerado um método de pesquisa no DAO que recebe um valor do mesmo tipo do atributo como parâmetro e retorna uma instância da entidade.
Por exemplo, se a sua entidade Aluno tem um atributo nome do tipo String, será gerado no DAO o seguinte método:

public Aluno searchUniqueNome(nome: String)

Caso esse método retorne mais de uma intância de Aluno, a exceção org.hibernate.NonUniqueResultException é disparada.

Simplificando Casos de Uso no cartucho andromda-jsf

2010-09-19T03:23:00.000-07:00

Uma coisa que sempre me incomodou na modelagem de atividades do cartucho andromda-jsf foi a obrigação de se modelar métodos para responder aos eventos. Apesar de considerar que é uma modelagem válida do ponto de vista da aderência quando os métodos são reutilizados, eu considero que o simples fato de existir o evento de saída do <<FrontEndView>> deveria gerar um "gancho" para o programador escrever sua lógica.
Finalmente agreguei essa simplificação ao cartucho andromda-jsf, de modo que agora o desenvolvedor não precisa criar métodos no controller se não quiser. Pode de fato deixar o controller completamente em branco e simplesmente sobrepor os (novos) métodos que são gerados no controller ancestral para responder aos eventos do usuário. Por exemplo, no modelo abaixo:
o controller não tem método nenhum e ao programá-lo, basta ao programador sobrepor o método _dadosDoAluno_confirmar da classe ancestral para executar a inclusão do aluno, fazendo com que a implementação do controller fique assim:

São gerados também métodos para cada estado de ação que não seja <<FrontEndView>>, mas é um caso mais complicado, porque são gerados métodos que atendam a todas as combinações de transições de entrada, eventualmente dificultando a programação. O melhor é sobrepor os eventos mesmo...

TextUML e Andromda

2010-08-05T07:39:00.000-07:00

Ontem fiz uma pequena experiência com o TextUML e o Andromda. Foi uma experiência pequena porém bem sucedida, consistindo na criação de uma aplicação com 2 CRUDs associados.
Entendo que a possibilidade de se programar modelos sem desenhá-los abre um leque de caminhos para aqueles que, como eu, gostam do desenvolvimento organizado e com visão de alto nível, não abrindo mão da agilidade no processo.
O que mais senti falta foi dos casos de uso e das máquinas de estado. Espero que o TextUML evolua logo nesse sentido para que possamos fazer modelagens completas de aplicações sem, obrigatoriamente, termos que desenhar.

DNS Dinâmico no Amazon EC2

2010-07-11T03:32:00.000-07:00

Recentemente passei a usar alguns servidores no Amazon EC2 para testar o ambiente e as possibilidades. Montei ambientes Ubuntu seguindo o AMI do Lucid disponibilizado pela Canonical.
Como eu queria ter acesso remoto ao ambiente desktop também, depois de criar os ambientes básicos eu instalei o Gnome e o NoMachine NX Server. Em poucas palavras, o NX Server (e o client) são uma forma MUITO eficiente de se acessar ambiente baseados em XWindows remotamente. É MUITO mais eficiente que o VNC, por exemplo.
Funcionou tudo muito bem, exceto por um detalhe: a cada vez que a máquina é ligada no EC2, ela ganha um IP novo... claro que a Amazon oferece um serviço de IP fixo, mas como esses ambientes são de teste, eu não queria inve$tir nada além do mínimo necessário.
Já uso o serviço de DNS do DNS Park e, depois de pesquisar muito consegui configurar o DDClient para atualizar o serviço de DNS dinâmico do DNS Park.
O arquivo de configuração do DDClient ( /etc/ddclient/ddclient.conf ) que usei foi:

daemon=300 # check every 300 seconds
syslog=yes # log update msgs to syslog
#mail=email@dnspark.com # mail all msgs to address
#mail-failure=email@dnspark.com # mail failed update msgs to address
pid=/var/run/ddclient.pid # record PID in file.

login=loginDoUsuarioDDNS # DNS Park DDNS username (NOT your DNS Park account login)
password=passwordDoUsuarioDDNS

use=cmd, cmd='curl http://169.254.169.254/2007-08-29//meta-data/public-ipv4'
protocol=dnspark subdominio.dominio.com.br #dominio que vc configurou no DNS Park para ser dinâmico

Um detalhe importante: em login/password não vai o seu login/password geral do DNS Park e sim um login específico para dns dinâmico que você cria livremente, no DNS Park.
Depois de testar na mão rodando do ddclient direto na linha de comando, montei o seguinte arquivo de configuração ( /etc/init/ddclient.conf ) para que o upstart do Ubuntu executasse o ddclient logo na inicialização:

# ddclient initialization

description "Starts ddclient"

start on (net-device-up
and local-filesystems)

exec /usr/sbin/ddclient

Funcionou que foi uma beleza. Todas as vezes que ligo a máquina o DDClient atualiza o IP no DNS Park e o meu sub domínio aponta para a máquina recém-ligada.

Paramêtros de Inicialização em Aplicações Web

2010-03-20T08:54:00.000-07:00

As aplicações baseadas em servidor tem características próprias no que diz respeito aos parâmetros de inicialização. Em aplicações locais pode-se optar por passar os parâmetros "na linha de comando", criar um arquivo de configurações ou usar variáveis de ambiente. Apesar de ser possível o uso de qualquer um dos método acima ( mais parâmetros de contexto/filtros/servlets) meu método predileto em aplicações em baseadas em servidor é a criação de variáveis de ambiente JNDI.
Esse tipo de variável de ambiente pode ser usado em servidores JavaEE em geral, ou seja: em servidores de servlets/EJB ou outros que suportem JNDI.
De volta aos servidores web, a vantagem que vejo desse tipo de parâmetro em relação aos parâmetros de contexto (<context-param/>) ou de filtros e servlets (<init-param/>) é que nesses casos é necessário que o arquivo web.xml seja alterado... ou seja: se você enviar um .war/.ear para ser disponibilizado, quem for disponibilizá-lo terá que alterar o arquivo web.xml que fica dentro do .war/.ear antes de colocá-lo no ar. Por outro lado, as variável de ambiente JNDI podem ser configuradas em arquivos de contexto ou ambientes de configuração externos. Por exemplo, para configurar um arquivo de contexto do Tomcat, usamos a entrada <Environment/>, conforme segue:

...
<Environment name="com.wim.jgnuteca.disableAllMonitors" type="java.lang.String" value="true"/>
...

Nesse caso o valor da variável poderia ser lido pela aplicação, por exemplo, com a seguinte classe:

...
/**
*
*/
package com.wim.jgnuteca;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

/**
* @author walter
*
*/
public class Config {

  private static String getContextParamValue(String parameter) throws NamingException {
    final Context ctx = new InitialContext();
    return (String)ctx.lookup("java:comp/env/"+parameter);
  }

  private static String DISABLE_ALL_MONITORS="com.wim.jgnuteca.disableAllMonitors";
  private static Boolean disableAllDTEMonitors=null;

  public static boolean disableAllDTEMonitors(){
    if(disableAllDTEMonitors == null){
      try{
        disableAllDTEMonitors=Boolean.valueOf(getContextParamValue(DISABLE_ALL_MONITORS));
      } catch(Throwable t) {
        disableAllDTEMonitors=false;
      }
    }
    return disableAllDTEMonitors;
  }

}
...

De fato essa classe poderia ser usada de forma genérica e lendo parâmetros de várias fontes. Teríamos então uma classe genérica de configuração independente do ambiente de execução da aplicação.

Inicialização do contexto Spring em testes unitários

2008-06-30T04:39:00.000-07:00

Durante o desenvolvimento de uma classe de testes na semana passada, decidi que ela devia acessar o banco da forma mais realista possível. Como a aplicação usa Spring/Hibernate e jndi, procurei solução para a questão da inicialização do ambiente. Optei por criar uma classe "helper" para garantir a inicialização e as classes de teste executam um método de inicialização dessa classe:

/**
*
*/
package com.arcadian.logOne.interfacedte;

import javax.naming.NamingException;

import org.apache.commons.dbcp.BasicDataSource;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.mock.jndi.SimpleNamingContextBuilder;

/**
* @author walter
*
*/
public class TestHelper {

    private static String[] springFiles = { "beanRefFactory.xml" };
    private static ClassPathXmlApplicationContext context=null;

    public static void startSpringContext() throws NamingException{

        if(context == null){//was not started
            BasicDataSource ds = new BasicDataSource();
            ds.setDriverClassName("org.postgresql.Driver");
            ds.setUsername("morganalborg");
            ds.setPassword("jpfr33");
            ds.setUrl("jdbc:postgresql://localhost/interfacedte_teste");

            SimpleNamingContextBuilder builder =
                    SimpleNamingContextBuilder.emptyActivatedContextBuilder();

            builder.bind("java:comp/env/jdbc/interfacedte", ds);

            context = new ClassPathXmlApplicationContext(springFiles);
        }
    }
}

Criando Aplicações Javaserver Faces com o AndroMDA - Parte 2

2008-04-20T12:30:00.000-07:00

Na segunda parte da apresentação acrescento uma classe e uma associação, com o objetivo de mostrar o comportamento do CRUD nessa situação. Mantêm-se 100% gerado pelo AndroMDA.

Criando Aplicações Javaserver Faces com o AndroMDA

2008-04-13T05:46:00.000-07:00

Criando Aplicações Javaserver Faces com o AndroMDA é uma apresentação em flash (minha primeira !) demonstrando a criação de uma aplicação simples com o AndroMDA. Essa apresentação tem dois objetivos: o primeiro é gerar interesse no AndroMDA em pessoas que não o conhecem. O segundo é servir como um roteiro para que está começando a usar o AndroMDA.
Aguardo críticas e sugestões :-).

Criptografia de Senha em Descritores de Contexto do Tomcat

2008-04-11T07:25:00.000-07:00

Recentemente um cliente reclamou, com razão, que as senhas de acesso aos bancos apareciam em texto não criptografado nos arquivos de contexto do Tomcat. Uma vez que essa senha vai direto para o driver jdbc, não encontrei outra forma de criptografar essa senha que não fosse criando meus próprios drivers jdbc, extendendo os drivers existentes.
No caso do Oracle, por exemplo, criei a classe abaixo:

public class OracleDriver extends oracle.jdbc.driver.OracleDriver {
static {
  try {
    java.sql.DriverManager.registerDriver(new OracleDriver());
  } catch (SQLException e) {
    e.printStackTrace();
  }
}
public static void main(String[] args) {
  System.out.println("Arcadian Oracle wrapper jdbc driver");
}
private static final String URL_PREFIX="jdbc:arcadian:oracle";
@Override
public Connection connect(String url, Properties info) throws SQLException {
  if(url.startsWith(URL_PREFIX)){//senha cryptografada
    Util.decryptPassword(info);
    return super.connect(url.replace(URL_PREFIX, "jdbc:oracle"), info);
  } else {//senha não criptografada
    return super.connect(url, info);
  }
}
@Override
public boolean acceptsURL(String url) {
  if(url == null)
    return false;
  else
    return url.startsWith(URL_PREFIX);
}
}

Dessa forma, o caso o url de acesso jdbc comece com o prefixo "jdbc:arcadian" eu sei que a senha está criptografada e o método Util.decryptPassword é chamado pelo método connect antes do método ancestral ser chamado.

Um datasource que use esse mecanismo deve ficar mais ou menos com o seguinte aspecto:

<resource name="jdbc/previne/datasource" auth="Container"
type="javax.sql.DataSource"
driverClassName="com.arcadian.commons.jdbc.OracleDriver"
url="jdbc:arcadian:oracle:thin:@120.120.126.209:5623:DBACC84C"
username="USER987"
password="ui#ghkuyt%--)(*CFR"
maxActive="10"
maxIdle="30"
maxWait="10000"/>
</resource>

Observe que para obter o mesmo efeito para outros bancos basta substituir a classe ancestral...

Autenticação X.509 (e-cpf) e FORM no Tomcat, simultâneamente

2008-03-21T05:20:00.000-07:00

Nessa semana tive um desafio interessante: como fazer uma aplicação que está rodando no Tomcat suportar tanto a autenticação comum (FORM ou BASIC) quanto via e-cpf (certificado cliente X.509), simultâneamente.

O Previne é uma aplicação voltada para empresas que fazem uso de regimes especiais da receita federal e tipicamente é acessada tanto pela empresa que a contrata quanto por fiscais da receita federal. A demanda era fazer com que o Previne suportasse a autenticação atual (FORM) no uso interno da empresa e via e-cpf para uso externo pelos fiscais da receita.

Fiz o trabalho de pesquisa tradicional e achei o excelente material Controle de Acesso com Certificação Digital usando JCE e JSSE desenvolvido por Ricardo Koji Ushizaki. Depois de construir o servlet de teste conforme indica a apresentação, me deparei com o fato de um mesmo web.xml não suportar duas marcações auth-method. A princípio pensei em usar uma válvula (Tomcat Valve) customizada, conforme o exemplo do wiki do tomcat, mas não fiquei muito seguro do funcionamento.

Finalmente optei pela seguinte solução: criei uma segunda aplicação autenticada via e-cpf que consiste somente de um servlet que redireciona para a aplicação destino e usei o recurso de single sign on do Tomcat. Dessa forma o usuário é autenticado na primeira aplicação e redirecionado para a segunda sem ter que passar por uma nova autenticação.

A grande vantagem que vi nessa solução foi que a aplicação original não sofreu nenhum tipo de manutenção e a aplicação que faz a autenticação ficou genérica, recebendo como parâmetro de contexto o caminho destino do redirecionamento de modo que pode ser usada com outras aplicações sem nenhuma alteração.

Autocomplete (Ajax) no JSF2

2008-03-14T04:33:00.000-07:00

O cartucho JSF2 ganhou um componente Ajax adicional, tipo "autocomplete". Esse componente foi desenvolvido usando somente Trinidad/Facelets para não incluir novas dependências no projeto.
O componente em si é independente do JSF2, ou seja: pode ser facilmente utilizado em projetos que não usam Andromda. Por outro lado tentei fazer com que o JSF2 o utilizasse de forma bem ampla e integrada.
Para vê-lo em ação, clique aqui, vá na opção "Reservar Material" e clique na lupa do campo "Usuário" ou digite nesse campo a(s) primeira(s) letras de algum usuário existente.
Espero em breve colocar no ar um pequeno projeto sem Andromda que faça uso do componente, como um exemplo de uso independente.

JasperReports no JGnuteca

2008-01-23T09:06:00.000-08:00

Implementei suporte a relatórios JasperReports no JGnuteca para demonstrar tanto o suporte ao JasperReports quanto o suporte a relatórios criados pelo próprio usuário, ou seja: o usuário, não necessariamente o programador, cria o relatório no iReport (por exemplo) e o publica de modo que o relatório esteja disponível imediatamente e possa ser executado por qualquer pessoa.
Para ver em funcionamento, clique aqui e selecione a opção "Manter Relatórios".
A maior dificuldade que se tem nesse tipo de funcionalidade diz respeito à apresentação e entrada dinâmica dos parâmetros. Essa implementação foi feita de forma simples, mas suporta essa característica, apresentando e repassando ao JasperReports os parâmetros que o usuário acrescentou ao relatório. O Facelets teve um papel importante uma vez que com o seu uso a página JavaServer Faces pode ser alterada dinamicamente, permitindo a montagem da página de entrada de parâmetros em tempo de execução da aplicação.
Atualmente somente parâmetros simples (texto, números, datas, etc.) são suportados, mas em uma próxima iteração pretendo adicionar suporte a seleção de valores (select, radio) e pesquisas (lookups) em tabelas.
Uma outra funcionalidade que considero importante é o suporte a segurança de modo que o usuário ao criar ou registrar o relatório possa indicar que grupos de usuários podem visualizá-lo. Também pretendo implementar essa funcionalidade no futuro, mas primeiro preciso implementar a segurança no JGnuteca ;-) .

RichFaces X Trinidad

2008-01-20T10:10:00.000-08:00

Tenho trabalhado como o Apache Trinidad (antigo Oracle ADF Faces) a 3 anos. Desde Julho passado participo de 2 projetos com RichFaces 3.1, minhas impressões e até agora:

o Trinidad tem mais componentes e é mais estável;
o RichFaces tem um visual mais "Web 2.0" por default, mas é possível fazer a aplicação Trinidad ter um visual semelhante, com um pouco de configuração;
no RichFaces o uso de Ajax é mais intuitivo do que no Trinidad, graças ao uso do Ajax4JSF;
os componentes do Trinidad são de mais alto nível (exemplo: painéis que organizam o conteúdo e entrada de dados com mensagem de erro e labels integrados);
ambos tem o suporte de empresas grandes. O Trinidad (mantido pela fundação Apache) é a base do ADF Faces da Oracle e o RichFaces é mantido pelo JBoss (leia-se Red Hat).

Tem dois outros pontos, mas acho que são muito subjetivos:

achei o suporte do Trinidad mais eficiente, mas não tenho números ou comprovação específica;
acho que a tendência do RichFaces é se integrar mais como o Seam do que ser um conjunto independente.

Se eu tiver que escolher um dos dois para um projeto novo, escolho o Trinidad... principalmente pela estabilidade, nível e quantidade de componentes.