Olá Pessoal,

Hoje nosso post será apenas uma curiosidade.
Segundo a spec da VM, a estrutura de um arquivo .class deve ser:

    ClassFile {
   	u4 magic;
    	u2 minor_version;
    	u2 major_version;
    	u2 constant_pool_count;
    	cp_info constant_pool[constant_pool_count-1];
    	u2 access_flags;
    	u2 this_class;
    	u2 super_class;
    	u2 interfaces_count;
    	u2 interfaces[interfaces_count];
    	u2 fields_count;
    	field_info fields[fields_count];
    	u2 methods_count;
    	method_info methods[methods_count];
    	u2 attributes_count;
    	attribute_info attributes[attributes_count];
    }    

Os 4 primeiros bytes desse arquivo, chamado de magic, idenfica que um arquivo é um class (“The magic item supplies the magic number identifying the class file format;”).

Ou seja, qualquer arquivo .class terá esse magic number que, em hexadecimal é nada mais do que 0xCAFEBABE ou simplesmente Cafe Babe.

Faça o teste! abra qualquer .class em um editor hexadecimal e veja o resultado…

Na linha de comando do Linux:

hexdump -C arquivo.class

Saída

00000000  ca fe ba be 00 00 00 32  00 81 0a 00 21 00 4a 0a  |Êþº¾...2....!.J.|
00000010  00 0f 00 4b 09 00 0f 00  4c 07 00 4d 0a 00 04 00  |...K....L..M....|
00000020  4a 0a 00 04 00 4e 0a 00  04 00 4f 07 00 50 09 00  |J....N....O..P..|
00000030  0f 00 51 08 00 52 0b 00  53 00 54 07 00 55 0a 00  |..Q..R..S.T..U..|

No emacs:

  emacs -nw arquivo.class

Mudar para modo hexadecimal:

- aperte Esc

- aperte x

- Digite: hexl-mode

Para sair:

- Crtl+X

- Crtl + C

Enviado por: Raoni Fortes Normanton
Desenvolvedor Java, Dextra Sistemas

Olá pessoal!

Este artigo, através de um exemplo simples de código, utiliza JBoss AOP para aprimorar seu comportamento, enquanto demonstra algumas das principais funcionalidades do framework. Vamos encapsular os interesses transversais da aplicação em aspectos, dar uma olhada em advices e nos novos advices leves que acompanham a versão 2.0 do JBoss AOP. Também estudaremos formas de adicionar interfaces às suas classes.

Baseado no texto original de Kabir Khan.

———-

O Servidor de aplicações JBoss possui suporte nativo à programação orientada a aspectos (Aspect-Oriented Programming ou AOP) em sua versão 5. Entretanto, o JBoss AOP também está disponível como um framework independente para uso use em aplicações executadas em JBoss.

Este artigo, aplica os conceitos de programação orientada a aspectos a um exemplo simples de código, aperfeiçoando o comportamento do código e ao mesmo tempo demonstrando algumas das principais funcionalidades do framework. O encapsulamento dos interesses transversais da aplicação em aspectos através de advices e nos novos advices leves que acompanham a versão 2.0 do framework JBoss AOP serãoo foco principal deste estudo.

Aplicação exemplo

O exemplo utilizado para a demonstração dos conceitos básicos de JBoss AOP é um simples aplicativo bancário. Ele possui uma classe BankAccount:

package bank;
public class BankAccount{

   private int accountNumber;
   private int balance;

   public BankAccount(int accountNumber){
      System.out.println("*** Bank Account constructor");
      this.accountNumber = accountNumber;
   }

   public int getAccountNumber(){
      return accountNumber;
   }

   public int getBalance(){
      return balance;
   }

   public void debit(int amount){
      System.out.println("*** BankAccount.debit()");
      balance -= amount;
   }

   public void credit(int amount){
      System.out.println("*** BankAccount.credit()");
      balance += amount;
   }
}

E adicionalmente, possui uma classe Bank:

package bank;

import java.util.HashMap;
import java.util.Map;

public class Bank{

   private static Map bankAccounts = new HashMap();

   public static void transfer(BankAccount from, BankAccount to, int amount){
      from.debit(amount);
      to.credit(amount);
   }

   public static void main(String[] args){
      System.out.println("*** Creating account 1");
      BankAccount acc1 = new BankAccount(1);
      acc1.credit(150);
      bankAccounts.put(acc1.getAccountNumber(), acc1);

      System.out.println("*** Creating account 2");
      BankAccount acc2 = new BankAccount(2);
      acc2.credit(230);
      bankAccounts.put(acc2.getAccountNumber(), acc2);

      System.out.println("*** Balance acount 1: " + acc1.getBalance());
      System.out.println("*** Balance acount 2: " + acc2.getBalance());

      //Transfer some money
      System.out.println("*** Transfer 50 from account 1 to account 2");
      transfer(acc1, acc2, 50);

      System.out.println("*** Balance acount 1: " + acc1.getBalance());
      System.out.println("*** Balance acount 2: " + acc2.getBalance());
   }
}

Como se observa, foram criadas duas contas de banco com seus números de conta, definidos os saldos iniciais de cada conta, e então foram transfedos $50 da contra 1 para a conta 2.

Quando este código é executado, a saída esperada é a apresentada abaixo:

*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
*** Balance acount 1: 100
*** Balance acount 2: 280

Logging: um interesse transversal à aplicação

Uma das principais motivações para o uso de programação orientada a aspectos é extrair do código de negócio da aplicação interesses transversais, geralmente não-funcionais. Supondo que seja necessário auditar a aplicação através de logging toda vez que um objeto for criado, quando valores forem atribuídos a seus campos, e quando seus métodos forem invocados. A maneira mais óbvia para este fim, e que foi utilizada no exemplo acima, consiste em acrescentar código de logging em diversos pontos do código da aplicação.

O problema desta abordagem é que pode ser necessário editar muitos pontos do código da aplicação, espalhados por todo o sistema, os quais deveria ser identificados, modificados para o acréscimo do código de logging, e posteriormente uma recompilação da aplicação seria necessária. Além disso, para este comportamento seja desligado, pode ser necessário remover todo o código de logging novamente e recompilar a aplicação uma vez mais. Assim, a maneira óbvia também é tediosa e difícil de ser mantida.

Utilizando AOP, é possível encapsular este interesse transversal no código de um aspecto. O aspecto em si é apenas mais uma classe Java, que pode manter estado, estender outras classes e tudo o que se pode fazer com uma classe Java.

package bank;

import org.jboss.aop.joinpoint.ConstructorInvocation;
import org.jboss.aop.joinpoint.FieldWriteInvocation;
import org.jboss.aop.joinpoint.MethodInvocation;

public class LoggingAspect{

   public Object log(ConstructorInvocation invocation) throws Throwable{
      try
         System.out.println("C: Creating BankAccount using constructor " + invocation.getConstructor());
         System.out.println("C: Account number: " + invocation.getArguments()[0]);
         return invocation.invokeNext();
      finally
         System.out.println("C: Done");
   }

   public Object log(MethodInvocation invocation) throws Throwable{
      try
         System.out.println("M: Calling method " + invocation.getMethod().getName());
         System.out.println("M: Amount " + invocation.getArguments()[0]);
         return invocation.invokeNext();
      finally
         System.out.println("M: Done");
   }

   public Object log(FieldWriteInvocation invocation) throws Throwable{
      BankAccount account = (BankAccount)invocation.getTargetObject();
      System.out.println("F: setting field " + invocation.getField().getName() + " for BankAccount " + account.getAccountNumber());
      System.out.println("F: Field old value " + account.getBalance());
      System.out.println("F: New value will be " + invocation.getValue());
      try
         return invocation.invokeNext();
      finally
         System.out.println("F: Field new value " + account.getBalance());
         System.out.println("F: Done");
   }
}

O código que implementa os interesses transversais é encapsulado em métodos do aspecto denominados advice. Os advice apresentados nesta sessão são do tipo around advice, e sua assinatura e formato são os seguintes:

public Object (org.jboss.aop.joinpoint.Invocation invocation) throws Throwable{

   //Faça alguma coisa antes

   try

      return invocation.invokeNext();

   finally

      //Faça alguma coisa depois

}

O parâmetro invocation pode ser do tipo org.jboss.aop.joinpoint.Invocation, ou alguma de suas subclasses. Algumas destas subclasses são apresentadas no aspecto LoggingAspect, e o método log sobrecarregado a ser chamado depende do que estiver sendo chamado no código de negócio quando o aspecto for aplicado. Em LoggingAspect é possível tratar chamadas a um construtor de objeto, (como é feito pelo primeiro método log() do aspecto), chamadas a um método de objeto (como é feito pelo segundo método log() do aspecto), e chamadas a métodos setXX() de um campo de objeto (como é feito pelo terceiro método log() do aspecto).

Estes eventos, ou pontos de entrada para a aplicação do aspecto, são chamados joinpoints na terminologia AOP. O parâmetro invocation contém informação sobre qual campo/método/construtor sendo invocado. Métodos advice do tipo around também devem conter uma chamada a Invocation.invokeNext(), que realiza a propagação da cadeia de chamadas. Se houver diversos métodos advice aplicados a um mesmo joinpoint, esta chamada invoca o próximo advice da cadeia. Se este for o último advice a cadeia, ou como no exemplo acima, se houver apenas um advice na cadeia, o código do joinpoint (ou seja o código executado no objeto de negócio) é chamado quando Invocation.invokeNext() é executado.

Para aplicar o aspecto de logging ao código de negócio, é preciso definir alguma configuração para declarar o aspecto, e selecionar os joinpoints na aplicação de exemplo, a partir de onde os métodos advice serão invocados. No JBoss AOP, ma maneira mais simples de se fazer esta configuração é através de um arquivo XML, tipicamente chamado jboss-aop.xml. Em primeiro lugar, o aspecto é declarado:

<aop>
<aspect class="bank.LoggingAspect"/>

Em uma tag bind é definida uma amarração, utilizando o atributo pointcut da tag para selecionar os métodos de negócio aos quais um dos métodos advice do aspecto devem ser aplicados. Neste caso, tem-se uma expressão de construtor, que seleciona o construtor da classe bank.BankAccount que possua um parâmetro int. É importante notar que todos os nomes de classes utilizados em uma expressão de pointcut devem ser completamente qualificados.

A palavra new é um identificador especial dentro da linguagem de definição de pointcuts, utilizada para selecionar um construtor. Em seguida, a parte around da amarração indica que o advice log do aspecto bank.LoggingAspect deve ser aplicado a todos os joinpoints do código de negócio aos quais a definição deste pointcut se aplica. Em outras palavras, quando o construtor da classe BankAccount for invocado, o primeiro método LoggingAspect.log(), que recebe como parâmetro um ConstructorInvocation, é invocado.

   <bind pointcut="execution(bank.BankAccount->new(int))">
     <around aspect="bank.LoggingAspect" name="log">
   </bind>

A amarração de pointcut anterior captura apenas um joinpoint. A próxima utiliza um coringa no lugar do nome do método, de forma que selecionamos todos os métodos que retornem void e que recebem um int como parâmetro, não obstante seu nome. Ela se parece muito com a expressão de construtor da amarração anterior, mas inclui o tipo de retorno dos métodos de interesse para logging. Este pointcut seleciona BankAccount.debit() e BankAccount.credit(), e invoca o segundo método LoginAspect.log() passando um MethodInvocation como parâmetro quando esses métodos são chamados.

<bind pointcut="execution(void bank.BankAccount->*(int))">
      <around aspect="bank.LoggingAspect" name="log"/>
</bind>

Finalmente, há uma amarração que captura as atribuições feitas ao campo de saldo (balance) da classe BankAccount. Neste caso, utiliza-se um coringa no lugar no nome do tipo, e o terceiro método LoggingAspect.log(), que recebe um FieldWriteInvocation, será invocado quando o campo tiver seu valor modificado.

<bind pointcut="set(* bank.BankAccount->balance)">
   <around aspect="bank.LoggingAspect" name="log"/>
</bind>

Além de coringas, também é possível capturar hierarquias de herança inteiras de classes, utilizando typedefs para expressões de classe complexas, capturar todas as classes pertencentes a um determinado pacote, e como será apresentado posteriormente, utilizar anotações para capturar uma ampla gama de joinpoints.

Para executar esta aplicação com AOP habilitada, é necessário passar alguns parâmetros extras para a JVM quando a aplicação for iniciada, como pode ser visto no build.xml do exemplo.

   <target name="run-load-time" depends="compile">
      <java fork="yes" failOnError="true" className="bank.Bank">
         <sysproperty key="jboss.aop.path" value="jboss-aop.xml"/>
         <jvmarg value="-javaagent:../libraries/jboss-aop-jdk50-single.jar"/>
         <classpath refid="classpath"/>
      </java>
   </target>

O parâmetro jboss.aop.path contém o caminho do arquivo jboss-aop.xml que declara os aspectos e amarra os métodos advice aos joinpoints. O argumento –javaagent aponta para a biblioteca do JBoss AOP, que liga o processo de weaving em tempo de carga (load-time weaving). Quando uma classe é carregada pela primeira vez, o JBoss AOP intercepta este evento e modifica o bytecode da classe para acrescentar os pontos de chamada requeridos à invocação dos aspectos relacionados aos joipoints selecionados.

Além de realizar o processo combinação (weaving) de código em tempo de carga das classes, você também pode combinar o código dos aspectos utilizando aopc post-processor. Um exemplo disso é mostrado no build.xml da aplicação exemplo. Ao executar o exemplo com load-time weaving, a seguinte saída é produzida, agora com muita informação extra vinda do aspecto de logging:

*** Creating account 1
C: Creating BankAccount using constructor public bank.BankAccount(int)
C: Account number: 1
*** Bank Account constructor
C: Done
M: Calling method credit
M: Amount 150
*** BankAccount.credit()
F: setting field balance for BankAccount 1
F: Field old value 0
F: New value will be 150
F: Field new value 150
F: Done
M: Done
*** Creating account 2
C: Creating BankAccount using constructor public bank.BankAccount(int)
C: Account number: 2
*** Bank Account constructor
C: Done
M: Calling method credit
M: Amount 230
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 0
F: New value will be 230
F: Field new value 230
F: Done
M: Done
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
M: Calling method debit
M: Amount 50
*** BankAccount.debit()
F: setting field balance for BankAccount 1
F: Field old value 150
F: New value will be 100
F: Field new value 100
F: Done
M: Done
M: Calling method credit
M: Amount 50
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 230
F: New value will be 280
F: Field new value 280
F: Done
M: Done
*** Balance acount 1: 100
*** Balance acount 2: 280

Externalizando Verificações de Segurança

Logging é o exemplo mais comumente utilizado para uma introdução a AOP, mas é possível fazer algo mais interessante. Supondo que seja necessário ter certeza de que apenas usuários com determinadas permissões possam chamar um método. Seria necessário anotar os métodos de BankAccount da seguinte maneira:

package bank;

public class BankAccount{

   private int accountNumber;
   private int balance;

   @Roles(roles= "admin")
   public BankAccount(int accountNumber){
      System.out.println("*** Bank Account constructor");
      this.accountNumber = accountNumber;
   }
   ...

   @Roles(roles= "admin")
   public void debit(int amount){
      System.out.println("*** BankAccount.debit()");
      balance -= amount;
   }

   @Roles(roles= "admin", "user")
   public void credit(int amount){
      System.out.println("*** BankAccount.credit()");
      balance += amount;
   }
}

De forma que apenas usuários com o perfil admin possam criar instâncias de BankAccount e debitar contas, enquanto que tanto o perfil admin quando o perfil user possam creditar contas. Para simular usuários com acesso ao sistema, suponha a existência de um arquivo security.properties contendo tais informações:

admin=password;admin,user
guest=password;user

Há um usuário chamado admin cuja senha é password e que tem os perfis admim e user, e um usuário chamado guest cuja senha é password e que possui apenas o perfil user.

É possível então aplicar um SecurityAspect aos métodos anotados com a anotação @Roles. Assim como tudo o mais na linguagem de pointcut, as anotações precisam ser completamente qualificadas. O símbolo “..” no lugar dos parâmetros na expressão de pointcut significa que se deseja que este aspecto seja aplicado a todos os construtores e métodos anotados com @Roles, a despeito dos parâmetros que recebam.

<aop>
   <aspect class="bank.SecurityAspect"/>

   <bind pointcut="execution(bank.BankAccount->@bank.Roles(..))">
      <around aspect="bank.SecurityAspect" name="checkSecurity"/>
   </bind>

   <bind pointcut="execution(* bank.BankAccount->@bank.Roles(..))">
      <around aspect="bank.SecurityAspect" name="checkSecurity"/>
   </bind>
</aop>

O aspecto SecurityAspect verifica que o usuário correto esteja sendo utilizado:

package bank;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.net.URISyntaxException;
import java.net.URL;
import java.util.Arrays;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;

import org.jboss.aop.joinpoint.Invocation;

public class SecurityAspect{

   private Map<String, String> usernamePassword = new HashMap<String, String>();
   private Map<String, List<String>> userRoles = new HashMap<String, List<String>>();

   public SecurityAspect() throws FileNotFoundException, IOException, URISyntaxException{
      //Inicializa o usernamePassword e o mapa userRoles
      //com informação do security.properties
   }   

   public Object checkSecurity(Invocation invocation) throws Throwable{
      String username = LoginInfo.getUsername();
      String password = usernamePassword.get(username);
      if (password == null)
         throw new SecurityException("Unknown user");
      if (!password.equals(LoginInfo.getPassword()))
         throw new SecurityException("Wrong password");
      Roles rolesAnnotaton = (Roles)invocation.resolveAnnotation(Roles.class);
      List<String> hasRoles = userRoles.get(username);
      boolean hasRole = false;
      if (hasRoles != null)
         for (String role : rolesAnnotaton.roles())
            if (hasRoles.contains(role))
               hasRole = true;
               break;
      if (!hasRole)
         throw new SecurityException("Wrong roles for user");
      return invocation.invokeNext();
   }

Os perfis necessários para a invocação do joinpoint alvo são obtidas do parâmetro invocation utilizando esta chamada:

Roles rolesAnnotaton = (Roles)invocation.resolveAnnotation(Roles.class);

Este código tem o mesmo efeito que a chamada java.lang.reflect.Method.getAnnotation() ou java.lang.reflect.Constructor.getAnnotation() para um método ou construtor, mas também permite redefinição de anotações como parte da configuração AOP, que está além do escopo deste artigo. Apesar do tipo de invocação utilizada neste exemplo ser Invocation, o tipo específico criado pelo JBoss AOP será ConstructorInvocation ou MethodInvocation, dependendo do que estiver sendo chamando. A classe LoginInfo é apenas um wrapper para alguns campos estáticos contendo username e senha.

package bank;

public class LoginInfo{

   private static String username;
   private static String password;

   public static void setUsernameAndPassword(String username, String password){
      LoginInfo.username = username;
      LoginInfo.password = password;
   }   

   public static String getUsername(){
      return username;
   }   

   public static String getPassword(){
      return password;
   }
}

Agora, o método Bank.main() será modificado para popular os campos de LoginInfo:

public static void main(String[] args){
      System.out.println("*** Log in as 'guest' - it does not have the correct roles to create an account");
      LoginInfo.setUsernameAndPassword("guest", "password");
      System.out.println("*** Attempting to create account 1");
      try
         BankAccount acc1 = new BankAccount(1);
         acc1.credit(150);
         bankAccounts.put(acc1.getAccountNumber(), acc1);
      catch(SecurityException e)
         System.out.println("!!! Expected SecurityException " + e.getMessage());
      System.out.println("*** Log in as 'admin' - the roles are fine for the rest now");
      LoginInfo.setUsernameAndPassword("admin", "password");
      System.out.println("*** Creating account 1");
      BankAccount acc1 = new BankAccount(1);
      acc1.credit(150);
      bankAccounts.put(acc1.getAccountNumber(), acc1);
      System.out.println("*** Creating account 2");
      BankAccount acc2 = new BankAccount(2);
      acc2.credit(230);
      bankAccounts.put(acc2.getAccountNumber(), acc2);
      System.out.println("*** Balance acount 1: " + acc1.getBalance());
      System.out.println("*** Balance acount 2: " + acc2.getBalance());
      //Transfer some money
      System.out.println("*** Transfer 50 from account 1 to account 2");
      transfer(acc1, acc2, 50);
      System.out.println("*** Balance acount 1: " + acc1.getBalance());
      System.out.println("*** Balance acount 2: " + acc2.getBalance());
}

Primeiro o método tenta criar uma BankAccount com um usuário que não possui o perfil admim requerido, e então o processo é repetido com um usuário que possui o perfil requerido. Quando a aplicação é executada, a seguinte saída é apresentada:

*** Log in as 'guest' - it does not have the correct roles to create an account
*** Attempting to create account 1
!!! Expected SecurityException Wrong roles for user
*** Log in as 'admin' - the roles are fine for the rest now
*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
*** Balance acount 1: 100
*** Balance acount 2: 280

Ao utilizar AOP para controle de segurança, as verificações de segurança foram extraídas para um local centralizado na aplicação e foram utilizadas anotações para configurar sinalizar os aspectos sobre onde aplicar a segurança. Se for desejável utilizar um mecanismo diferente de configuração de usuários, é possível manter o núcleo de negócio da aplicação intacto, escrever um outro aspecto e modificar facilmente a maneira como a segurança é aplicada em toda a parte do sistema modificando o arquivo jboss-aop.xml.

Métodos Advice Leves

Os méodos advice vistos até o momento são do tipo around, que tem sido parte do framework JBoss AOP desde seu início. Eles permitem adicionar comportamento antes e depois da invocação do joinpoint alvo. Como visto, estes advice recebem como argumento um parâmetro do tipo Invocation, ou uma subclasse desta. Em uma aplicação com muitos pontos de aplicação de aspectos, toda vez que for necessário invocar um joinpoint que possua métodos advice aplicados a ele, o framework AOP precisará instanciar o objeto Invocation, e isto pode causar algum reflexo no desempenho da aplicação.

Para alinhar o framework ao que é oferecido por outros frameworks de AOP, foi introduzido o conceito de métodos advice leves, que não requerem a instanciação de um objeto Invocation. O objeto Invocation contém muita informação conceitual a respeito do que está sendo chamado, mas ainda é possível obter boa parte desta informação por outros meios. De volta a exemplo de logging, pode-se reescrever LoggingAspect sobre o que fazer quando campos são modificados:

package bank;

import org.jboss.aop.advice.annotation.Arg;
import org.jboss.aop.advice.annotation.JoinPoint;
import org.jboss.aop.advice.annotation.Target;
import org.jboss.aop.joinpoint.FieldAccess;

public class LoggingAspect{

   public void logBefore(@JoinPoint FieldAccess fieldAccess, @Target BankAccount account, @Arg int value){
      System.out.println("F: setting field " + fieldAccess.getField().getName() + " for BankAccount " + account.getAccountNumber());
      System.out.println("F: Field old value " + account.getBalance());
      System.out.println("F: New value will be " + value);
   }

   public void logAfter(@Target BankAccount account)[
      System.out.println("F: Field new value " + account.getBalance());
      System.out.println("F: Done");
   }
}

O método log original foi dividido em dois métodos. Um advice do tipo before, logBefore(), que será disparado ates do campo ser modificado, e um advice do tipo after, logAfter(), que será disparado após o campo ser modificado. Para o método logBefore(), o parâmetro fieldAccess, anotado com @JoinPoint?, contém informação sobre o campo a ser modificado, o parâmetro account, anotado com @Target, recebe o objeto cujo campo será modificado, e o parâmetro value, anotado com @Arg, recebe o novo valor que será atribuído ao campo.

De maneira análoga, para o método logAfter(), o parâmetro account, anotado com @Target, recebe o objeto cujo campo foi modificado. É importante notar que como os métodos advice leves nunca recebem um parâmetro Invocation, não há necessidade de se chamar Invocation.invokeNext(). O framework JBoss AOP sabe quais advices chamar antes e após uma chamada ao joinpoint alvo. Para amarrar estes advices, é utilizado o seguinte xml:

<aop>
   <aspect class="bank.LoggingAspect"/>
   <bind pointcut="set(* bank.BankAccount->balance)">
      <before aspect="bank.LoggingAspect" name="logBefore"/>
      <after aspect="bank.LoggingAspect" name="logAfter"/>
   </bind>
</aop>

Esta declaração é similar ao exemplo de logging anterior, mas ao invés de utilizar around nesta amarração, foi utilizada uma entrada before e uma entrada after, especificando que logBefore() deve ser chamado antes do campo ser modificado e logAfter() deve ser chamado após o campo ser modificado. Ao executar este exemplo temos a seguinte saída:

*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
F: setting field balance for BankAccount 1
F: Field old value 0
F: New value will be 150
F: Field new value 150
F: Done
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 0
F: New value will be 230
F: Field new value 230
F: Done
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
F: setting field balance for BankAccount 1
F: Field old value 150
F: New value will be 100
F: Field new value 100
F: Done
*** BankAccount.credit()
F: setting field balance for BankAccount 2
F: Field old value 230
F: New value will be 280
F: Field new value 280
F: Done
*** Balance acount 1: 100
*** Balance acount 2: 280

Além dos tipos before e after, também é possível utilizar advices do tipo throwing, que são chamados quando o joinpoint alvo lança uma exceção, e advices do tipo finally, que são chamados após o joinpoint alvo, não obstante uma exceção ter sido ou não lançada pelo joinpoint. Como vimos, advices do tipo after são chamados após a execução o joinpoint alvo, desde que nenhuma exceção tenha sido lançada por ele.

Observer com introduções de interfaces e mixins

Supondo que fosse necessário enviar uma notificação de alguma maneira quando o saldo da conta bancária for modificado. Uma opção para implementar este comportamento seria implementar o padrão de projeto Observer, mas é indesejável incluir todo o código de infra-estrutura deste padrão na classe BankAccount. Primeiramente, considere uma anotação ao campo balance, que será monitorado.

package bank;

public class BankAccount{

   int accountNumber;

   @Observed
   int balance;
   ...
}

Em seguida, uma implementação de Observable:

package bank;

import java.util.ArrayList;
import java.util.List;

public class ObservableMixin implements Observable{

   private List observers = new ArrayList();

   public void addObserver(Observer listener){
      observers.add(listener);
   }

   public void removeObserver(Observer listener){
      observers.remove(listener);
   }   

   public void notifyObservers(Object event){
      for (Observer observer : observers){
         observer.update(event);
      }
   }
}

Esta é uma classe mixin, que implementa a interface Observable. Ela contém todo o código de infra-estrutura necessário para a parte Observable do padrão. E pode ser introduzida em POJOs utilizando o seguinte xml:

<aop>
   <introduction expr="hasfield(* *->@bank.Observed)">
      <mixin>
         <interfaces>
            bank.Observable
         </interfaces>
         <class>bank.ObservableMixin</class>
      </mixin>
   </introduction>
      ...

Este xml faz duas coisas. Primeiramente, faz com que todas as classes que tenham um campo anotado com @Observed implemente a interface Observable e seus méodos. Em segundo lugar, quando alguém tenta chamar os métodos da interface Observable, as chamadas são delegadas para uma instância da interface ObservableMixin.

A seguir, um aspecto é declarado para monitorar campos anotados com @Observed quando estes são modificados, conforme mostra o seguinte xml:

...
   <aspect class="bank.ObserverAspect"/>
   <bind pointcut="set(* bank.BankAccount->@bank.Observed)">
      <around aspect="bank.ObserverAspect" name="fieldChanged"/>
   </bind>
</aop>

O aspecto é um advice do tipo around que captura os valores antes e depois da modificação do campo.

package bank;

import java.lang.reflect.Field;

import org.jboss.aop.joinpoint.FieldWriteInvocation;

public class ObserverAspect{

   public Object fieldChanged(FieldWriteInvocation invocation) throws Throwable{
      Observable tgt = (Observable)invocation.getTargetObject();
      Field fld = invocation.getField();
      String fieldName = fld.getName();
      fld.setAccessible(true);
      Object oldVal = invocation.getField().get(tgt);
      Object result = invocation.invokeNext();
      Object newVal = invocation.getField().get(tgt);
      tgt.notifyObservers("Changed " + fieldName + " from " + oldVal + " to " + newVal);
      return result;
   }
}

Como as classes capturadas pelo pointcut são classes que implementam a interface Observable, é seguro realizar um casting para esta interface. Então, os valores antes e depois da modificação do campo são registrados e a interface Observable é utilizada para notificar os observadores a respeito da modificação. Conforme mencionado, a chamada a Observable.notifyObservers() acabará sendo respondida pela classe ObservableMixin.

Finalmente, o método Bank.main() será modificado para registrar um Observer com uma instância de BankAccount.

   public static void main(String[] args){
      System.out.println("*** Creating account 1");
      BankAccount acc1 = new BankAccount(1);
      acc1.credit(150);
      bankAccounts.put(acc1.getAccountNumber(), acc1);

      System.out.println("*** Creating account 2");
      BankAccount acc2 = new BankAccount(2);
      acc2.credit(230);
      bankAccounts.put(acc2.getAccountNumber(), acc2);

      System.out.println("Installing observer");
      ((Observable)acc2).addObserver(new Observer()
         public void update(Object evt)

            System.out.println("!!! Observer: " + evt);

      );

      System.out.println("*** Balance acount 1: " + acc1.getBalance());
      System.out.println("*** Balance acount 2: " + acc2.getBalance());

      //Transfer some money
      System.out.println("*** Transfer 50 from account 1 to account 2");
      transfer(acc1, acc2, 50);

      System.out.println("*** Balance acount 1: " + acc1.getBalance());
      System.out.println("*** Balance acount 2: " + acc2.getBalance());
   }

Apesar de a classe BankAccount não implementar a interface Observable até que o processo de weaving tenha ocorrido, o compilador Java não realiza nenhuma verificação quando o casting para uma interface é realizado (apenas para uma superclasse), portanto, o casting de BankAccount para Observable irá compilar. (Se o exemplo for executado sem weaving, um ClassCastException será disparado pois BankAccount não implementará a interface Observable). Quando este exemplo é executado, pode-se ver quando o Observer registrado é notificado:

*** Creating account 1
*** Bank Account constructor
*** BankAccount.credit()
*** Creating account 2
*** Bank Account constructor
*** BankAccount.credit()
Installing observer
*** Balance acount 1: 150
*** Balance acount 2: 230
*** Transfer 50 from account 1 to account 2
*** BankAccount.debit()
*** BankAccount.credit()
!!! Observer: Changed balance from 230 to 280
*** Balance acount 1: 100
*** Balance acount 2: 280

Conclusão

Partindo de uma aplicação simples e adicionando comportamento extra a ela usando JBoss AOP, algumas das características oferecidas pelo framework foram exploradas. Além de adicionar algumas anotações para auxiliar expressões de pointcut, (e ainda há maneiras menos intrusivas, se bem que mais inconvenientes, de se obter um efeito similar), o núcleo da aplicação foi mantido intacto, e comportamento transversal extra foi adicionado, tal como logging e segurança, com a aplicação de aspectos, bem como pela combinação de aspectos, introdução de interface e mixins para implementar o padrão Observer.

Enviado por: Paulo Crestani
Desenvolvedor Java, Dextra Sistemas

Como dissemos no primeiro post, a equipe de desenvolvedores Java da Dextra irá postar uma série de artigos e dicas sobre desenvolvimento neste Blog, e como primeiro post, iremos apresentar uma dica sobre Regex (expressões regulares).

Várias vezes precisamos utilizar expressões regulares para validar algum campo ou para extrair partes dele.

Normalmente, quando queremos dizer que há caracteres alfanuméricos em uma expressão, utilizamos o \w. Porém ele se limita à classe [a-zA-Z_0-9], não incluindo os caracteres acentuados. O que fazíamos era adicionar nesta classe estes caracteres um a um, mais ou menos assim: [\wÁáÉé].

Para facilitar nossa vida, há um range que inclui todos estes caracteres: À-ú, deixando nossa classe  bem mais simples:

[\wÀ-ú]
ou a String em java: “[\\wÀ-ú]”

Esperamos que esta dica tenha sido útil para você

Enviado por: Raoni Fortes Normanton
Desenvolvedor Java, Dextra Sistemas

Como um meio de compartilhar experiências de desenvolvimento Java com a comunidade,  a Dextra abriu este canal pelo qual a equipe de desenvolvedores irá postar uma série de artigos e dicas sobre a tecnologia. Serão abordados assuntos que exponham experiências e reflexões sobre o dia-a-dia do desenvolvimento de aplicações.

Sejam todos bem vindos!

Equipe de Desenvolvimento Java - Dextra Sistemas