Scala is going into production at work! Very exciting, even if the details of the deployment put Scala in a humble introductory role. Amidst all this excitement a huge collection of stack traces slipped by my attention, most of which look akin to :

java.lang.ClassCastException: org.aspectj.weaver.MissingResolvedTypeWithKnownSignature cannot be cast to org.aspectj.weaver.ReferenceType

and the line:

java.lang.RuntimeException: Can't find type scala.collection.mutable.ListBuffer$$anon

Every time one of these exceptions show up they are related to an inner Java class. Of particular interest was this message I dug up in the aspectj-users mailing list which suggests that AspectJ isn’t particularly intelligent about how it determines the outer class, which, Scala has many of!

The solution for this particular problem was to make a custom META-INF/aop.xml file the details of which are in the AspectJ developer’s guide! Simple, really… just a little elusive when staring at a giant stack trace in your QA system. Specifically, adding an <exclude>scala..*</exclude> line did the trick in the <weaver> section. Notice that there are supposed to be 2 dots in the exclude tag value. The second dot is for regular expression matching.

Now for those wondering, AspectJ is being used in this instance for loadtime weaving of Java classes as they are loaded (hence the computation of inner or outer classes). What is very exciting is wiring up monitoring code and performance code around classes based on what package they are a part of, including the new Scala code! We just have to be aware that the inner-outer class assumption of Java aren’t quite the same. We also need to keep an eye on what possible performance impact this has in our Spring Application Context as we need AspectJ around for some transaction management.

It’s recommended to read Simple caching with AspectJ before you continue. Only difference is in using Spring AOP.
At first we need to create spring-config.xml and define Spring beans and enable Spring AOP autoproxy for AspectJ:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:aop="http://www.springframework.org/schema/aop"
	xsi:schemaLocation="http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
		http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

	<aop:aspectj-autoproxy />
	<bean class="caching.springaop.CacheAspect" />

	<bean id="calc" class="caching.springaop.Calculator" />

</beans>

Now we can use Calculator bean created by Spring:

ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config.xml");
Calculator calc = (Calculator) ctx.getBean("calc");

// result will be calculated and stored in cache
logger.info("1 + 2 = " + calc.sum(1, 2));

// result will be retrieved from cache
logger.info("1 + 2 = " + calc.sum(1, 2));

Download full source code as a zip or tar.gz file or browse code online on GitHub.

Caching hasn’t been never so easy to implement before. AspectJ is one of the best (probably the best) technologies that can be used for implementing caching system.

There are several ways how to do caching. Object can directly set values to cache, can implement some caching interface or can be fancy and use annotations that sounds to me as a most elegant solution. With annotation you can annotate any method that should be cached. Could be something easier?

Let’s create @Cacheable annotation:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Cacheable {

}

With this annotation we can mark any expensive, time consuming methods whose results should be cached. For example let’s create Calculator class that has one very expensive and time consuming method. Every time we call this method with same input it will be executed. It’s a huge wasting of resources. So we will use our @Cacheable annotation on it’s function to prevent executing it when it’s not necessary.

public class Calculator {

	private Logger logger = Logger.getLogger(Calculator.class);

	@Cacheable
	public int sum(int a, int b) {
		logger.info("Calculating " + a + " + " + b);
		try {
			// pretend this is an expensive operation
			Thread.sleep(3000);
		} catch (InterruptedException e) {
			logger.error("Something went wrong...", e);
		}
		return a + b;
	}

}

Next we need to create an aspect called CacheAspect that will handle caching. In this aspect we define pointcut that matches all methods annotated with @Cacheable, regardless of number and type of input arguments and return type:

@Pointcut("execution(@Cacheable * *.*(..))")
private void cache() {}

It is a best practice to annotate empty methods with a pointcut. Function cache() can be considered as a name for a pointcut.
As a last step we need to create an advice – a function that wraps calling of cacheable methods. This function will be actually called every time empty function cache() is invoked. Advise aroundCachedMethods will take a look into cache for a previously cached result and return it. If it couldn’t find anything then it will call our time consuming function and store result for next reuse.

@Around("cache()")
public Object aroundCachedMethods(ProceedingJoinPoint thisJoinPoint)
		throws Throwable {
	logger.debug("Execution of Cacheable method catched");

	// generate the key under which cached value is stored
	// will look like caching.aspectj.Calculator.sum(Integer=1;Integer=2;)
	StringBuilder keyBuff = new StringBuilder();

	// append name of the class
	keyBuff.append(thisJoinPoint.getTarget().getClass().getName());

	// append name of the method
	keyBuff.append(".").append(thisJoinPoint.getSignature().getName());

	keyBuff.append("(");
	// loop through cacheable method arguments
	for (final Object arg : thisJoinPoint.getArgs()) {
		// append argument type and value
		keyBuff.append(arg.getClass().getSimpleName() + "=" + arg + ";");
	}
	keyBuff.append(")");
	String key = keyBuff.toString();

	logger.debug("Key = " + key);
	Object result = cache.get(key);
	if (result == null) {
		logger.debug("Result not yet cached. Must be calculated...");
		result = thisJoinPoint.proceed();
		logger.info("Storing calculated value '" + result + "' to cache");
		cache.put(key, result);
	} else {
		logger.debug("Result '" + result + "' was found in cache");
	}

	return result;
}

Download full source code as a zip or tar.gz file or browse code online on GitHub.

I haven’t posted in a while. It’s not that I haven’t been doing anything, it’s just that what I was doing was the basic stock and trade of any programmer – coding. J2EE with a bit of Google’s Web Toolkit (GWT) thrown in. And none of it pays the bills… just a hint to anyone out there with work that needs doing.

It’s not been a week without discovery though. I’ve been using Apache for quite a few years now and thought I knew it pretty well. Heck, I’ve even written Apache modules! But I’ve always been a bit of a small time user in that I’ve never worked on anything that really pushed it to the limits, except in a test environment. When I started testing my GWT application though, all that changed. Performance was sluggish, taking upwards of 30 seconds to load a page when tested remotely. This is obviously unacceptable, but I’d made no effort on the performance side, so I wasn’t really surprised. I’ve made a living developing and using tools that model the differences between a testing laboratory and the real world. And my real world consisted of multiple tiers that were actually multiple virtual machines running on my development machine and a DSL link (i.e. high speed on the requests, not on the responses) connected through DDNS. Of course it’s slow.

YSlow to the rescue. It’s a great plugin for Firefox from the folks at Yahoo that measures why pages are slow to load and more importantly offers suggestions for improvement. The first thing it suggested was I use mod_deflate to compress my files. I didn’t even know you could do this! Where have I been? What a difference this made! I’m now down to about 3 seconds a page.

Of course, it had other suggestions as well, including cache settings, ETags, and so on. I’m not so worried about them yet, as I’m still in pretty active development, but they’re good to know. Overall, GWT is pretty cache friendly, but there are some files, such as my CSS files, that are still changing pretty quickly. It did surprise me though how limited the configuration options are for Apache when it comes to caching files. I can set options according to a mime type, but not according to a file pattern. This would be useful for caching files such as *.cache.* and *.nocache.*. These are questions that will have to be addressed either by module or by process before deployment, but I’m happily ignoring them for now.

The other tool that’s been really useful is Firebug. This was required for YSlow, but the best use I made of it was in debugging my CSS. It allowed me to look at individual elements and discover what styles were being applied. This is very useful when using GWT as the styles may not always be what you expect. It definitely reduced the amount of cursing I did.

Then again, perhaps the most significant event of the last couple of weeks is that there were no significant events. My life as a programmer has taught me to expect otherwise.

There’s another week or so of heads down development, but then I tackle interesting things again, such as instrumenting Geronimo with ARM. AspectJ, here we come!

Jednym z niepożądanych zjawisk dość często pojawiających się przy tworzeniu aplikacji w oparciu o programowanie zorientowane obiektowo jest nadmierny rozrost metod. Najczęściej muszą one wykonać szereg dodatkowych operacji (sprawdzenie uprawnień, poprawności danych, logowanie czynności, itp.) zanim przystąpią do wykonywania głównego zadania. Często można sobie z tym poradzić uwzględniając takie ewentualności w projekcie aplikacji, zwykle nie jest to jednak idealne rozwiązanie. W tym celu powstała idea programowania zorientowanego aspektowo, które jest przystosowane właśnie do radzenia sobie z tego typu problemami.

Podstawowe założenia

Programowanie zorientowane aspektowo w żadnej swojej formie nie wyklucza programowania obiektowego. Właściwie to jest jego uzupełnieniem dostarczającym dodatkowe elementy pozwalające inaczej spojrzeć na projekt aplikacji. Aspektowe języki programowania pozwalają na wskazanie miejsc w kodzie obiektowym w których mają zostać wykonane dodatkowe operacje. Istnieje wiele implementacji tego, lecz zdecydowanie najbardziej popularny jest AspectJ stworzony dla Javy. Wprowadza on następujące elementy:

• pointcut – ogólny opis miejsca przecięcia kodu w którym mają zostać wykonane operacje definiowane przez aspekt. W większości sytuacji jest to wywołanie lub wykonanie kodu funkcji składowej, ale możliwe jest także zdefiniowanie pointcuta przy każdej operacji wykonanej przez metody w danej klasie. Pointcuty mogą także dotyczyć każdego dostępu do pola lub tworzeniu obiektu.
• joinpoint – konkretne miejsce przecięcia kodu w którym zostaną wstawione dodatkowe operacje definiowane przez dany aspekt.
• advice – definiuję operację jaka ma zostać wykonana w joinpointach. Kod opisany w advices jest najczęściej wstawiany przed lub po wywołaniu metody w klasie, ale także w przypadku rzucenia wyjątku lub oryginalna funkcja składowa zostaje całkowicie przez niego zastąpiona.

W przypadku AspectJ a także wielu innych języków aspekt jest traktowany jak klasa. Oprócz wyżej opisanych elementów może zawierać funkcje składowe lub pola. Mogą być tworzone ich instancje, ale najczęściej aspekt jest singletonem. Dodatkowo można utworzyć hierarchię aspektów korzystając z dziedziczenia. Wiele implementacji pozwala także na istnienie abstrakcyjnych aspektów oraz wirtualnych pointcutów.

Realizacja

W przypadku Javy i AspectJ aspekty są realizowane w czasie kompilacji z niewielkim wsparciem refleksyjności dzięki czemu nie wpływają w dużym stopniu na wydajność. W przypadku AspectC++ w związku brakiem wsparcia dynamicznego metaprogramowania ze strony C++ kod aspektowy (napisany w AspectC++) jest najpierw tłumaczony do kodu obiektowego (C++) i dopiero wtedy kompilowany. Bibliotek wprowadzająca aspekty w C# LOOM.NET wykonuje wszystkie operacje z tym związane podczas działania programu, podobnie rzecz się ma w przypadku modułu Perla Aspect. Generalnie sposób realizacji jest inny dla różnych bibliotek i także powinien być świadomym wyborem ponieważ, może w dość dużym stopniu wpłynąć na wydajność programu.

Zastosowanie

Najbardziej oczywistymi zastosowaniami programowania aspektowego to wszelkiej maści loggery i narzędzia diagnostyczne. Można także użyć ich do kontrolowania zgodności otrzymanych danych z kontraktami, ale należy pamiętać, że wiele zalet aspektów jest zauważalna dopiero wtedy gdy odnoszą się do tych samych operacji wykonywanych w wielu metodach. Przykładem może być realizacja wzorca Obserwator, gdzie każda zmiana stanu obiektu obserwowanego wymaga poinformowania o niej obiekty obserwujące. W tym przypadku najlepszym rozwiązaniem jest wstawienie po wywołaniu każdej metody (nie oznaczonej jako const) klasy obiektu obserwowanego wywołania metody uaktualniającej obiekty obserwujące.

Przykład

Warto przedstawić prosty przykład użycia aspektów w realizacji wzorca Obserwator. Zwykłe podejście wymagałoby czegoś podobnego do kodu poniżej:

class Obserwowany {
	// ...
	public void metoda1(int wartość) {
		// ... operacje ...

		uaktualnijObserwatorów();
	}

	public void metoda2(string tekst) {
		// ... operacje ...

		uaktualnijObserwatorów();
	}
}

W przypadku AspectJ kod realizujący te same funkcje mógłby wyglądać następująco:

class Obserwowany {
	// ...
	public void metoda1(int wartość) {
		// ... operacje ...
	}

	public void metoda2(string tekst) {
		// ... operacje ...
	}
}

aspect WzorzecObserwator {
	pointcut operacja() : execution(public * Obserwowany.*(..));
	after() : operacja() {
		uaktualnijObserwatorów();
	}
}

Ten przykład bardzo dobrze prezentuje główne założenie aspektów. Jest nim pozbycie się często powtarzanego kodu niezwiązanego z głównym przeznaczeniem metody z jej kodu. Taka izolacja ma na celu sprawienie kodu bardziej przejrzystym i ułatwienie wprowadzenia ewentualnych zmian.

Problemy

Głównym problemem związanym z programowaniem aspektowym jest fakt, że sam pomysł jest stosunkowo młody i w związku z tym wsparcie jest wciąż niewielkie. O ile ze znalezieniem odpowiednich narzędzi nie powinno być problemów to kwestia przyzwyczajenia programistów i to, że języki modelowania takie jak UML nie zostały stworzone z myślą o aspektach sprawiają, że wciąż nie zyskało dużej popularności.

Podsumowanie

Programowanie aspektowe, mimo że z niskopoziomowego punktu widzenia nie zmienia praktycznie niczego, to bez wątpienia jest w stanie wprowadzić pewne uporządkowanie w miejscu gdzie typowe programowanie obiektowe pozostawiło dużą swobodę. Rozwiązanie ciekawe, ale jest tylko jednym z wielu sposobów na ominięcie pewnych problemów co sprawia, że nie odnosi, jak na razie, spektakularnych sukcesów.

Today I’d like to introduce a library that proved to be really useful in my last project at work: what I’m talking about is AspectJ, a framework allowing you to introduce AOP (Aspect Oriented Programming) in your applications.

First of all, what is AOP?

Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by allowing the separation of cross-cutting concerns, forming a basis for Aspect-oriented software development. Introduced after Object-oriented programming (OOP), it is a post-object-oriented programming paradigm.

Wikipedia

To explain what AspectJ is and how it works I will use an example that comes from the last project I worked on.

This was our requirement:

Realize an monitoring infrastructure for the application, allowing you to trace where something went wrong and, in response to that, either take some corrective actions or just log what caused the error.

Surely there are a whole lot of solutions out there: we could use Log4J to trace every little event in our application, just to mention one of them… But that would require a lot of “intrusive code”. AspectJ gives us a workaround for this case. Let’s see how it works.

Our sample class will be a really simple class representing a number:

public class MyNumber {

double number;

public MyNumber(String number){

this.number = parse(number);

}

private double parse(String number){

return Double.parseDouble(number);

}

public double getNumber(){

return this.double;

}

}

Just as a remainder, Double.parseDouble() method throws a NumberFormatException (unchecked exception) whenever the input String is not a valid number… So if you look at the code, this means that this.number could be not initialized. This will be our AspectJ class:

@Aspect

public class MyNumberAj {

@Pointcut(“execution(* MyNumber.parse(..)) && args(number)”)

private void monitorParse(String number){

}

@Before(“monitorParse(number)”)

public void start(String number){

System.out.println(“Trying to parse ” + number);

}

@AfterReturning(pointcut=”monitorParse(number)”, returning=”parsedNumber”)

public void parseSucceded(String number, double parsedNumber){

System.out.println(“Succeded in parsing: ” + number + ” to ” + parsedNumber);

}

@AfterThrowing(pointcut=”monitorParse(number)”, throwing=”exception”)

public void parseFailed(String number, JoinPoint jp, Throwable exception){

System.out.println(“Failed parsing: ” + number);

MyNumber mn = (MyNumber) jp.getThis();

if(exception instanceof NumberFormatException){

mn.number = 0;

}

System.out.println(“Number value reset to: ” + mn.getNumber());

}

}

Ok, I introduced a bunch of new things… Most of the work here is define the correct annotations for what you need… Let’s see what they mean:

@Aspect: identifies MyNumberAj as an AspectJ class;

@Pointcut: it’s like saying to AspectJ “Stay here and tell me what happens, I will tell you what I need to know later on”, the here being the method within brackets;

@Before, @AfterReturning, @AfterThrowing: On the line above I wrote “[...]I will tell you what I need to know later on“. Ok, the time is now By defining a Pointcut I’m placing an Advice on the method’s events and by defining, for example, Before, I’m saying “call me right after parse() method has been called but before executing the method’s code”… Based on this, AfterReturning and AfterThrowing are self-explaining, I hope.

Let’s examine the parseFailed() method: first of all, it is called only if the parse() method in MyNumber threw an exception. The code is really easy to understand, i’d just like to point out on the MyNumber mn = (MyNumber) jp.getThis() line, that obtains an instance of the class under watch from the JoinPoint object. Last, this.number wasn’t initialized because the parse() method threw an exception: I will initialize it now, after verifying that the exception thrown was really a NumberFormatException.

Whenever you write an Advice you need to keep in mind some gold rules:

• An Advice must have at least all the parameters as the method it is watching (at least because our advice may have some more parameters, as it happens for parseFailed() for example);
• Parameters are obviously positional, and if you include JoinPoint and returning values (or throwing values) they should be placed as last. For example, public void parseFailed(String number, JoinPoint jp, Throwable exception): method’s parameters are placed in first position(String number), even if there are more than one; then comes the JoinPoint and then the Throwable (or the return value). Should you misplace them, you will get a strange exception message which doesn’t help you at all in understanding what happened, so be careful.

In conclusion, AspectJ is not merely another logging framework (remember that I modified an instance variable in one advice), it all depends on how you choose to use it.

I’ve just had one of those mornings where you spend hours trying to crack a problem and just getting nowhere.

The problem was getting AspectJ to work under Ant but only by using the AJDT 1.6.3 Eclipse plugin.

Unfortunately, this is very poorly documented. Fortunately, this helps you make the right decision: don’t use AspectJ in Ant by relying on AJDT.

There is a very good reason for this (beyond it being hard to get working): you cannot rely on AJDT being available when compiling in anything other than Eclipse (e.g. from a CI server).

What’s the alternative? Download AspectJ and use these libraries directly in Ant – they’re well documented and just work.

@Configurable is a very nice Spring 2.x feature that enables rich domain models with ORM tools like hibernate. I expect to expand on rich domains in a next post. For now I will explain how to use @Configurable.

@Configurable uses AspectJ aspects in order to inject dependencies in non managed classes, I mean, classes that aren’t instantiate by spring but directly by the programmer (with operator new) or by a ORM framework.

There are two ways to enable AspectJ aspects. Run-time weaving (usually requires a special agent attached to the VM) and build-time weaving (no special configuration on the server required).

For build-time weaving AspectJ makes available a ant task that can be used along with eclipse.

Here goes a example:

<project name="aspectwaving" default="compile" >
<taskdef resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties">
<classpath>
<pathelement location="lib/aspectjtools.jar"/>
</classpath>
</taskdef>

<target name="compile" >
<!-- destDir: output folder. Xlingwarning, showWeaveInfo: detailed information about weaving -->
<iajc destDir="build/classes/" Xlintwarnings="true" showWeaveInfo="true" aspectPath="lib/spring-aspects.jar" debug="true">
<inpath>
<!-- Pathelement: output folder followed by the package containing the classes to be weaved -->
<pathelement location="build/classes/com/mycompany"/>
</inpath>
<classpath>
<!-- JARs the target classes depend upon -->
<pathelement location="lib/aspectjrt.jar"/>
<pathelement location="lib/spring.jar"/>
</classpath>
</iajc>
</target>
</project>

aspectjtools.jar and aspectjrt.jar comes with AspectJ distribution. spring-aspects.jar come with Spring distribution.

To integrate with Eclipse, select project properties -> builders -> new -> ant build and select the build file as shown in the example above.

This aproach has few drawbacks:

• Eclipse don’t always runs the weaving when using “build automatically” option. A clean/build should resolve the problem.

• If you don’t use “build automatically” option, each build will take extra five seconds for the weaving process. This is bad when using small development cycles like TDD.

If the problems above bother you, you may use AJDT instead.

More info about configurable and rich domains can be found here:

Anemic Domain Models

Migrating to Spring 2: Part 3 – injecting dependencies into entities

I am thinking of starting with AspectJ.

A presentation by Gregor Kiczales

http://video.google.com/videoplay?docid=8566923311315412414

Some links :

1. http://www.eclipse.org/aspectj/downloads.php
2. http://www.eclipse.org/aspectj/doc/released/progguide/index.html
3. http://www.eclipse.org/aspectj/doc/next/index.html
4. http://yakafokon.wordpress.com/2008/12/02/beans-binding-jsr-295-with-pojo-and-aop/
5. http://wordpress.com/tag/aspectj/
6. http://www.ibm.com/developerworks/library/j-aopwork1/
7. http://www.java2s.com/Code/Java/Spring/AspectJExamplefromProSpring.htm

I would post something soon if I really do something with it

(download the net beans project : BeansBindingTest.zip.ppt : rename to .zip before opening)

Beans binding (JSR 295) is about keeping two properties in sync. To take a Simple example, let say that you have a simple text field (the view) in a Swing form and that you want it to be kept in sync with a POJO (the data model).

In a small first part I show how this can be done the standard way and in a second part how we can enhanced it we some simple AOP.

Part 1 : the standard way

Here the simple user form that we will create and bind with our data model :

And here the PersonVO.java POJO to be used as data model :

public class PersonVO {

  private String name;
  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }
}

public class PersonVOBindingEnabled extends PersonVO {
  protected PropertyChangeSupport props = new PropertyChangeSupport(this);
  public void addPropertyChangeListener( PropertyChangeListener l) {
    System.out.println("addPropertyChangeListener");
    props.addPropertyChangeListener(l);
  }

  public void removePropertyChangeListener( PropertyChangeListener l) {
    System.out.println("removePropertyChangeListener");
    props.removePropertyChangeListener(l);
  }

  public void setName(String newName) {
    String oldValue = getName();
    super.setName();
    props.firePropertyChange("name", oldName, newName);
  }
}

To bind the name attribute with the JTextField we use the Beans binding API :

JTextField nameTextField =…

PersonVO aPersonVO = new PersonVO();

aPersonVO.setName(“Brian”);

…

BeanProperty nameProperty = BeanProperty.create("name");

Binding b = Bindings.createAutoBinding(UpdateStrategy.READ_WRITE, aPersonVO, nameProperty, nameTextField, BeanProperty.create("text"));

And that’s it !

If you change the name attribute on the aPersonVO instance it will be sync in the JTextField and vice versa.

Yes but …

Having to extend the PersonVO so that it gets the PropertyChangeSupport is really annoying so it could be great if we could find a way to avoid it.

Part 2 : Using AOP

I have used AspectJ to automatically find my VO objects and add them all the necessary stuff for us :

package beansbindingtest.aspects;

import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import org.apache.commons.beanutils.PropertyUtils;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.DeclareParents;

public @Aspect class PropertyChangeListenerAspect {
  public interface ChangeListener {

  public void addPropertyChangeListener( PropertyChangeListener l);
  public void removePropertyChangeListener( PropertyChangeListener l);
  public String getPropertyName(String setterMethodName);
  public PropertyChangeSupport getPropertyChangeSupport();
}

public static class ChangeListenerImpl implements ChangeListener {

  protected PropertyChangeSupport props = new PropertyChangeSupport(this);

  public void addPropertyChangeListener( PropertyChangeListener l) {
    System.out.println("addPropertyChangeListener");
    props.addPropertyChangeListener(l);
  }

  public void removePropertyChangeListener( PropertyChangeListener l) {
    System.out.println("removePropertyChangeListener");
    props.removePropertyChangeListener(l);
  }

  public String getPropertyName(String setterMethodName) {
    setterMethodName = setterMethodName.substring(3);
    String firstLetter = setterMethodName.substring(0, 1);
    setterMethodName = firstLetter.toLowerCase() + setterMethodName.substring(1);
    return setterMethodName;
  }

  public PropertyChangeSupport getPropertyChangeSupport() {
    return props;
  }
}

  @DeclareParents(value="beansbindingtest.datamodel.*",defaultImpl=ChangeListenerImpl.class)
  private ChangeListener implInterface;

  @Around("execution(void *..*VO.set*(..))")
  public void interceptSetterAndFirePropertyChange(ProceedingJoinPoint pjp) throws Throwable {
    System.out.println("before " + pjp.getSignature().getName());
    String setterMethodName = pjp.getSignature().getName().substring(3);
    String firstLetter = setterMethodName.substring(0, 1);
    String propertyName = firstLetter.toLowerCase() + setterMethodName.substring(1);
    Object oldValue = null;
    try {
      oldValue = PropertyUtils.getProperty(pjp.getTarget(), propertyName);
    } catch (Exception e) {
      e.printStackTrace();
    }
    Object newValue = pjp.getArgs()[0];

    pjp.proceed();

    System.out.println("Firing event : " + propertyName + "; oldValue = " + oldValue + "; newValue = " + newValue);
    PropertyChangeEvent pe = new PropertyChangeEvent(pjp.getTarget(), propertyName, oldValue, newValue);
    ((ChangeListener)pjp.getTarget()).getPropertyChangeSupport().firePropertyChange(pe);
    System.out.println("after " + pjp.getSignature().getName());
  }

}

I have used the following jars :

• aspectjrt-1.5.4.jar
• aspectjweaver-1.5.4.jar
• commons-beanutils-1.8.0.jar
• commons-logging-1.1.1.jar

aop.xml has to be copied in the META-INF directory of your source.

And you need to add these args to the JVM when starting the application :

-javaagent:[set your path here]/aspectjweaver-1.5.4.jar

What is your opinion about using AOP for bean binding ?

No último artigo apresentei os conceitos básicos da Programação Orientada a Aspectos. Nesse artigo pretendo mostrar um exemplo prático de um problema muito comum em aplicações “enterprise”, a auditoria.

A auditoria é o processo de registrar todas as mudanças feitas pelos usuários para que se possa provar as ações tomadas por eles. Dessa forma é possível provar que o sistema não estava errado. Por exemplo, os dados sumiram porque alguém os excluiu.

Auditoria é uma responsabilidade “cross-cutting”, ou seja, se for programada de maneira tradicional estará espalhada por todo o sistema. Entretanto, é possível implementar tal funcionalidade utilizando técnicas de AOP, como veremos a seguir.

Dando continuidade ao artigo anterior, os exemplos estarão utilizando Spring e @AspectJ.

Exemplo Inicial

Começamos definindo uma interface geral para que nossos objetos de acesso ao banco de dados possam implementar, seguindo o padrão de projeto “Data Access Object”.

Utilizamos o recurso de tipos genéricos para que nossas implementações possam inserir qualquer tipo de objeto do domínio.

Para não complicar o exemplo a implementação da interface apenas imprimirá no console para sabermos que o método foi executado, porém imagine que poderíamos estar executando código JDBC ou Hibernate/JPA em seu lugar.

Agora implementaremos a primeira versão do nosso aspecto de auditoria, que simplesmente irá interceptar as execuções dos métodos inserir, atualizar e remover, imprimindo no console uma mensagem de aviso.

Note o uso do advice @AfterReturing para que o aspecto seja aplicado após uma execução com sucesso do método alvo. No pointcut interceptamos execuções de métodos de objetos que implementam a interface EntityDao, como a classe ConsoleClienteDao que criamos acima.

Para completar o exemplo mostramos o applicationContext.xml e o método Main para teste da aplicação.

A execução do método main irá imprimir o seguinte no console:

executou inserirCliente
depoisDeInserir
executou atualizarCliente
depoisDeAtualizar
executou removerCliente
depoisDeRemover

Agora, de posse de um exemplo muito simples, iremos melhora-lo para contemplar funcionalidades mais reais.

Auditando dados da entidade

Vamos criar uma superclasse abstrata para nossas entidades, dessa forma podemos utilizar o aspecto para obter informações de auditoria.

A classe Entity possui um id e um método a ser implementado pelas subclasses para obter uma String descritiva para auditoria. Em um sistema real poderíamos criar um POJO para substituir a String, de forma que ele poderia conter informações mais avançadas. Agora nossa classe Cliente passa a estender a classe Entity.

Para ter acesso aos dados da entidade que está sendo auditada podemos utilizar a expressão ‘args’ da sintaxe de pointcut do @AspectJ. Veja o exemplo abaixo.

Agora restringimos o método inserir a ter apenas um parâmetro, e do tipo Entity. Na expressão args(entity) definimos o nome do parâmetro, essa string deve coincidir com a variável declarada como parâmetro do método depoisDeInserir. Sendo assim, o objeto disponibilizado para o método é o mesmo passado como parâmetro do ConsoleClienteDao, e podemos utiliza-lo para auditoria.

Outra forma possível de auditar os dados da entidade seria utilizar a API de reflection para obter todas as suas propriedades, e então, montar uma descrição com a concatenação de seus valores.

Auditando mudanças nas atualizações

Em geral na auditoria, quando um objeto sofre um update, é desejável auditar as mudanças realizadas. Mas como podemos saber as mudanças feitas antes do update ocorrer? Podemos fazer um select antes e comparar os dados antes e depois da atualização.

Isso pode ser facilmente contemplado utilizando um advice @Around. Antes da execução do método atualizar fazemos um select e obtemos o objeto em seu estado atual, depois da atualização com sucesso, comparamos os dois objetos utilizando reflection (ou alguma interface), e então, auditamos o resultado.

Para manter os exemplos simples apenas comparamos os objetos com o método equals. Alem disso, nenhum tratamento foi feito para evitar NullPointerExceptions. Note que o método proceed executa o método alvo e em caso de exceções, será propagado para fora do aspecto, sem chegar a executar as ultimas linhas do método.

Filtrando quais classes participarão da auditoria

Imagine que para uma determinada aplicação é necessário fazer auditoria em apenas alguns DAO’s. Mas queremos que nosso aspecto continue consistente, ou seja, não sofra alterações constantemente. Para tal, uma idéia interessante é a utilização de anotações para marcar o pointcut do aspecto. Veja o exemplo abaixo.

Veja a expressão @target(exemplo.AptoParaAuditoria). Essa expressão significa que para o pointcut ser atingido a classe alvo tem que estar anotada com a anotação @AptoParaAuditoria. Dessa forma, a auditoria só ocorre quando desejado, nos DAO’s marcados com essa anotação. Também é possível criar filtros a nível de método utilizando a expressão @annotation(exemplo.AptoParaAuditoria).

Para melhorar o exemplo ainda é possível criar um atributo na anotação, uma enumeração, para informar em quais operações serão auditadas: inserir, atualizar, remover ou todas.

Obtendo informações do usuário corrente

Em um sistema de auditoria não basta saber o que foi feito e onde, também é necessário saber quem fez a alteração. Ou seja, é necessário obter dados do usuário logado. Em uma aplicação web isso se torna difícil, pois é impossível obter um objeto HttpRequest ou HttpSession de dentro do aspecto de auditoria.

Para essas situações existe uma técnica muito utilizada na AOP, associar recursos a Thread corrente. Assim é no Spring na área de controle de transações. Quando uma transação é aberta pelo aspecto de transação é associado a Thread corrente um java.sql.DataSource ou, no caso do Hibernate, uma org.hibernate.classic.Session. Dessa forma, ao longo da execução da Thread, de todos os lugares, é possível obter o mesmo recurso de conexão (na mesma transação), para executar o acesso ao banco de dados.

Essa solução pode ser aplicada nesse caso. Podemos implementar um filtro http (javax.servlet.Filer) que associa o request a Thread corrente. Dessa forma, de dentro do aspecto, podemos acessar o HttpRequest. Na verdade, o Spring já possui tal filtro implementando dentro do spring-web.jar, basta declararmos no web.xml.

Agora de dentro do aspecto de auditoria é possível acessar o request e a session desta forma:

Conclusão

A Programação Orientada a Aspectos é muito útil para funcionalidades como auditoria provendo sempre uma solução transparente. O Spring já nos traz vários recursos implementados que se utilizados de forma correta podem poupar muitos esforços. O @AspectJ está muito bem integrado com o Spring Framework, e o casamento das duas tecnologias pode trazer grandes benefícios.

Abraços,
Michel Zanini.

I want to post the SE-Radio.net Episode 106 about AOP programming and two nice presentations from slideshare.net.

AOP importance is increasing in the past few years, Spring are using it in a widely manner and also OSGi have announced few month ago your Aspect bundle for weaving at run-time (Equinox Aspect). So AOP have a grait impact on present programming and I think that it will have also with future programming.

This episode is a systematic introduction to Aspect Oriented Programming (in contrast to the interview with Gregor Kiczales). We discuss the fundamentals of AOP, define many of the relevant terms and also look at how and where AOP is used in practice, as well as at some current research trends.

Host(s)

Guest(s)

Christa Schwanninger,
Iris Groher

Follow I have posted from slideshare.net two good presentations to AOP.

Aspect-Oriented Programming and Depedency Injection

Aspect Oriented Software Development

Have fun!

[se-radio.net]

Nesse artigo vou explicar os conceitos básicos de AOP e mostrar um exemplo inicial de como isso é feito utilizando @AspectJ 5 e Spring.

A Programação Orientada a Aspectos (AOP) complementa a programação orientada a objetos, provendo uma nova forma de pensar sobre a arquitetura da aplicação.

Na programação orientada a objetos encapsulamos as responsabilidades em classes. Já na AOP, as responsabilidades são encapsuladas em um aspecto. Um aspecto permite a modularização de interesses que geralmente aparecem espalhados por várias classes do sistema (denominados de interesses transversais – crosscutting concerns), como o gerenciamento de transações, por exemplo.

Veja a imagem abaixo. Se compreendermos as linhas horizontais como classes, veremos que os interesses de segurança, transação, etc. são transversais, ou seja, repetidos entre várias classes. A AOP contribui no sentido de retirar essas funcionalidades das classes e encapsula-las em aspectos, sem alterar o comportamento do sistema.

Conceitos

Aspect: é a unidade modular (funcionalidade) que encapsula interesses que atravessam vários objetos dentro do sistema.

Join Point: é um ponto durante a execução do programa que poderá ser afetado pelo aspecto. Um join point pode ser, por exemplo, a execução de um método do programa.

Point Cut: é uma expressão escrita em uma linguagem específica para a finalidade de selecionar join points (pontos de execução).

Advice: quando um join point é atingido, e selecionado pelo point cut, uma ação será executada. Essa ação é determinada advice.

Objeto Alvo: é o objeto que está sendo interceptado por um ou mais aspectos.

Proxy AOP: é o objeto criado pelo framework AOP para implementar a ligação entre o aspecto e o objeto alvo.

Veja na imagem abaixo. Durante a execução do programa, vários join points serão “atingidos”. No suporte a @AspectJ do Spring Framework (veremos exemplos a seguir) um join point é sempre a execução de um método. Dessa forma, imagine que cada um dos 6 join points abaixo representem 6 diferentes métodos. Um point cut é uma expressão, em linguagem específica, que seleciona quais dos 6 métodos (join points) serão afetados pelo aspecto. Nesse caso, imagine que os 3 joint points verdes foram atingidos pela expressão pointcut. O advice é a ação que irá executar quando eles foram atingidos, nesse caso, o advice será executado 3 vezes.

Tipos de Advice

No AspectJ existem 5 tipos diferentes de advice:

• Before: ação do advice executa antes do join point.

• After returning: ação do advice executa depois do joint ser executado com sucesso, ou seja, sem lançar exceção.

• After throwing: ação do advice executa depois do joint ser executado com erro, ou seja, somente quando ele lançar uma exceção.

• After (finally): ação do advice executa depois do joint ser executado independente de ter causado ou não exceção.

• Around: advice que envolve a execução de um joint point. Com ele é possível codificar ações antes e depois do join point. Inclusive é possível alterar valores passados como parâmetro, como retorno, ou nem mesmo chamar o método do objeto alvo.

Exemplo concreto utilizando o suporte a @AspectJ com Spring

A partir da versão 2.0 do Spring Framework é suportado o uso do @AspectJ 5 de forma integrada ao seu container. Ainda é possível declarar aspectos por XML, como nas versões anteriores, porém agora é possível declarar aspectos com uso de anotações.

Para implementar um aspecto é necessário três coisas:

• Colocar os jars ‘aspectjrt.jar’ e ‘aspecjtweaver.jar’ no classpath, juntamente com os jars tradicionais do Spring.

• Declarar no applicationContext.xml o uso de aspectos com declaração por anotações, dessa forma:<aop:aspectj-autoproxy />.

• Criar uma classe anotada com @Aspect para definir o aspecto. Utilizar uma anotação de advice (before, after ou around) e definir uma expressão point cut para selecionar quais joint points o aspecto afetará.

Veja um exemplo abaixo:

Repare que a expressão “execution(* xyz.abc.ClienteDao.*(..))” é o point cut e a anotação @Before é o advice. A linguagem do point cut é específica do @AspectJ e sua documentação pode ser encontrada no site da biblioteca. Explicando a expressão em detalhes:

• execution: Qualquer execução de método.

• Primeiro asterisco da expressão: que tenha qualquer visibilidade e retorne qualquer tipo de parâmetro.

• xyz.abc: pacote que estão a(s) classe(s) que o point cut afetará.

• ClienteDao: a classe afetada pelo point cut.

• Segundo asterisco da expressão: qualquer método da classe ClienteDao.

• (..): O método pode ter qualquer quantidade de parâmetros, de qualquer tipo.

Dessa forma podemos dizer que o método ‘realizarAcao’ será executado antes que qualquer método da classe ClienteDao executar.

É importante lembrar que o suporte à @AspectJ do Spring, como mostrado no exemplo, só selecionará join points que forem beans gerenciados pelo Spring. Ou seja, no exemplo acima o ‘ClienteDao’ tem que ser um bean no application context do Spring.

No próximo artigo veremos como implementar uma solução simples de auditoria utilizando AOP com Spring e @AspectJ.

Abraços,
Michel Zanini.

Martin Lippert is a senior consultant and coach at akquinet it-agile GmbH. His main work and research focuses on Agile Software Development, Refactoring, Eclipse-Technology, OSGi, Spring and Aspect-Oriented Programming.

• Eclipse Monitor Demo
• Dependency Injection with Spring Dynamic Modules and Equinox Aspects

Eclipse Monitor Demo

This demo features the relatively old Eclipse Monitor application that Chris Laffra wrote a while ago. It visualizes plugin activities within your Eclipse application and you can analyze what is going on. This monitor uses Equinox Aspects to weave an aspect into all your bundles at load-time to gather the information of what is going on at runtime. It uses AspectJ advises for all methods and object creations. While this is a pretty heavy use of load-time weaving (you will notice a huge performance impact at first startup) it demos nicely the caching feature of Equinox Aspects. The second startup of your monitored app will perform very similar to a startup without any aspect weaving. (more)

Dependency Injection with Spring Dynamic Modules and Equinox Aspects

Spring provides this nice mechanism to inject dependencies in domain objects via the @Configurable annotation (see more here: http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-atconfigurable).
The main difference to general spring beans is that the creation of those domain objects is not done by the application context of Spring. Therefore Spring uses an aspect to call the application context after object creation to inject all necessary dependencies. In plain old Spring applications this aspect is woven into the system using load-time weaving.
Wouldn’t that be a nice mechanism to inject dependencies into Eclipse extensions (like views or editors)? Just annotate your extension with @Configurable and define the dependencies to be injected inside the application context of your bundle (using the Spring Dynamic Modules stuff)? (more)

[http://martinlippert.blogspot.com]

In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.

Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they “cut” across multiple modules in a program.

Any AOP language has some crosscutting expressions that encapsulate the concern in one place. The difference between AOP languages lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to intercept express a limited form of crosscutting, without much support for type-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, like adding members or parents.

Many AOP languages support method executions and field references as join points. In them the developer can write a pointcut to match, for example, all field-set operations on specific fields, and code to run when the field is actually set. Some also support things like defining a method in an aspect on another class. AOP languages can be compared based on the join points they expose, the language they use to specify the join points, the operations permitted at the join points, and the structural enhancements that can be expressed.

AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely-used de-facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

Equinox Aspects: the goal is to allow developers to use the Equinox together with AspectJ by combining the benefits of both worlds. Using a load-time weaving extension you are able to add AspectJ aspects to your bundle-based system just by putting them into general OSGi bundles. It does not matter if the pointcuts you defined inside the aspects contain join points that are defined by classes within the same bundle or any other bundle in your installation. The load-time weaving extension will take care that your aspects are woven with the appropriate classes at load-time.

Finally aspects become dynamic (Martin Lippert)

I recently committed some changes to the Equinox Aspects project which allows the Equinox Aspects runtime to handle dynamically uninstalled aspects correctly with regards to the woven bundles in the system. Having this it was only a small step to also deal with dynamic updates to aspect bundles as well as woven bundles at runtime. And now, finally, we are there: real dynamics for aspects. You can install, update and uninstall aspects at runtime as you like and the Equinox Aspects runtime takes care that everything will be woven and re-woven correctly. This is really really cool and a huge step towards real OSGi-enabled AOP, I think.

But what happens if aspect bundles are installed, updated or uninstalled at runtime? All other bundles that need to be woven, that need to be re-woven or that need to be un-woven from the aspect are updated automatically by the aspect runtime using the OSGi mechanisms. This means also that your system should be able to deal with OSGi dynamics and bundles coming and going (which is not a trivial thing to do). So be a good citizen of the OSGi world and your bundles will behave well when aspects are coming and going at runtime…

Code Examples from “Aspect Weaving for OSGi” Talk

Slides from “Aspect Weaving for OSGi” Talk

References:

[http://martinlippert.blogspot.com]

[wikipedia.org]

[http://www.eclipse.org/equinox/incubator/aspects/]

Задача: покрутить AOP на как можно более простом примере.

Для этого возьмем:

1) Файл AspectTest.java с подопытным классом

package ajtest;

class AspectTest {
    public void printKrivetko() {
        System.out.println("Я криветко  ");
    }

    public void printMedved() {
        System.out.println("Я медвед 8]");
    }

    public static void main(String[] args) {
        AspectTest app = new AspectTest();
        app.printKrivetko();
        app.printMedved();
    }
}

2) Файл PrintLogging.aj с простым аспектом

package ajtest;

// наш простой аспект
public aspect PrintLogging {

    // наш простой адвайс
    after() returning:
        call(void AspectTest.print*()) {
        System.out.println("^^^ вызыван какой-то метод print*");
    }
}

3) Файл build.xml с несложным проектом

<project name="ajtest" default="ajx" basedir=".">
    <!-- определяем директории для исходников и скомпилированных классов -->
<property name="src" location="src"/>
<property name="build" location="build"/>

    <!-- определяем таск iajc -->
    <taskdef
        resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties">
        <classpath>
<pathelement location="lib/aspectjtools.jar"/>
        </classpath>
    </taskdef>

    <!-- цель для компиляции основных классов -->
    <target name="compile">
        <javac srcdir="${src}" destdir="${build}"/>
    </target>

    <!-- цель для добавления AOP-функциональности -->
    <target name="ajx" depends="compile">
        <iajc sourceroots="${src}"
              destdir="${build}"
              classpath="lib/aspectjrt.jar"
        />
    </target>
</project>

4) Библиотеки aspectjrt.jar и aspectjtools.jar из последнего стабильного билда.

Все это разложим по директориям:

+ build
+ src
|- + ajtest
   |- AspectTest.java
   |- PrintLogging.aj
+ lib
|- aspectjrt.jar
|- aspectjtools.jar
build.xml

И соберем ant-ом:
ant

Запускаем (сообщения, создаваемые внутри аспекта, отправляются в стандартный вывод):
java -cp build;lib/aspectjrt.jar ajtest.AspectTest

В консоли должно появиться следующее:
Я криветко
^^^ вызыван какой-то метод print*
Я медвед 8]
^^^ вызыван какой-то метод print*

It’s working.

Some time ago, on my previous blog, I wrote a short series of articles showing real live examples of using AOP. It is time to group them together and share with you again:

• Introduction and caching example Transparent Caching with AspectJ
• Tracing history of bean with AspectJ in 10 minutes
• Retry if failed pattern with AspectJ in 10 minutes
• @Configurable without Spring in 10 minutes

Enjoy!