Simon Wacker

Portal systems are web-based applications that provide information to users from different sources. Every user can purposefully assemble and maintain the information he wanna see by a personalization mechanism. The users can access the portal via various terminals depending on the portal system. This system formats the information for the particular terminal and allows for displaying it in different ways. Handy, PDA and Webbrowers are possible terminals that can be used for presenting the information.
The portal allows for showing the aggregated information from different sources in a uniform manner. This saves the user from having to become acquainted with various systems with different styles of presenting information.
Jetspeed is a well-known enterprise imformation portal of the Apache Software Foundation that builds on Java and XML. Its component architecture is based on the Springframework.

I started working for msg at.NET and my first task was to rewrite an old ColdFusion application using the Mach II Framework. This was mainly done for comparison reasons, to see if it would pay off doing projects with Mach II. Because I am a little bit into Java, and Java is definitely my favourite programming language so far, I offered expand the little research and compare these two ColdFusion applications with a Java solution. The Java solution was programmed using the Spring Framework, a light-weight Java container.
Download the application for ColdFusion and Java (note that this is not the original program I had to convert but a simpler one).
The first thing I encountered was that writing an application in Java is as easy as writing it in ColdFusion. So there is no difference in that spectrum. This is at least true for someone that knows some basics about Object-Oriented Programming.
When comparing the two solution directly there is no question that the application written in Java is more flexible and easier to maintain. This is achieved due to the use of Java’s great language features like interfaces, abstract classes and type checking combined with good practices like inversion of control.
It is no problem to switch from one database to another or even change the database type. These changes have no effect on the underlying code. These capabilites also make testing easier. You can easily write stub implementations or mocks to test the application without the need to set up a database.
The changes can be made without redeploying the whole application. All important settings can be done declaratively in xml files.

As you can see there are nearly no restrictions or functionalities missing what is not true for the ColdFusion solution. So let’s take a closer look at it.

Because of the help of the Mach II Framework our control-flow is now managed in one file, mach-ii.xml. While this is a great thing there are some declarative options missing. It is said that listeners shall only be used as facades to let business logic not depend on the framework. But there is no possibility set up a reference to these framework independent components, declare basic properties like the name of the database and reference these components in the listeners.
The control-flow shall be handled in the event-handlers. But because no simple if-else statements can be declared, some logic has to be moved into listeners. This produces mishmash of event-handler and listener managed control-flow logic.
Another problem for a programmer who knows what listeners, events and event-handlers are is the naming. For example listeners that should be nontransparent for event-handlers are this not at all. The event-handler even decides which method to call on the listener and where to store the result. An even-handler is a on xml-basis declared method that handles the control-flow.
A disadvantage is also the, at least for me scaring, tag-based object-oriented scripting language. As well as the fact of bad type checking, the inability to use interfaces and other useful object-oriented constructs.

This is at least my experience so far. So, my question is, why are people working with ColdFusion?

A cool mechanism AspectJ offers is to declare compile-time errors and warnings. You can use this mechanism to ensure that certain rules specified in a specification don’t get broken. For example Swing’s single-thread rule. You declare errors using the following syntax:

and warings using a similar one:

Errors as well as warnings will be issued when the compiler detects a join point matching a given pointcut. Errors would abort the compilation process, while warnings would just be displayed.

Example:

This would produce an error if you’d call a join point captured by the pointcut callToHiddenCode().

One thing I haven’t talked about yet is passing context from a join point to an advice. An advice often needs certain information about the join point. For example the arguments passed to the join point, the class the join point is declared in and so on. All this information is called context. There do exist special pointcuts to capture these context. ApsectJ provides the following: this(), target() and args(). Let’s directly step into it:

We have a package called org.swacker.geom. In this package are by now two classes, Rectangle and Circle. These two classes implement the interface Shape. This interface declares one method: fill(newColor:Color). What we want to do is logging the calls to any class implementing this interface and printing out the name of this class as well as the new color the shape shall be filled with. Our final ouput shall look like this:

To achieve this we somehow must get down to the target of the call as well as the arguments passed to the method. What we need is the target() and args() pointcut. We have everything we need now. Thus let’s start coding:

We’ll now walk through this step by step.
We have an advice specification: before(Shape shape, Color color). It’s a before advice that collects some context. An instance of type Shape and another of type Color. What we also have are three pointcuts that are connected by && operators. We firstly capture all calls to the method fill() that is implemented in the class Shape or any of its subclass: call(void Shape+.fill(Color)).
Then we say that the target of the call shall be mapped to the context named shape in the advice specification: target(shape).
What we also do is taking the first argument of the method call and say that it shall me mapped to the context named color. This mapping will now be done automatically and we can use the context to build our output: System.out.println(”About to fill a ‘” + shape.getClass().getName() + “‘ instance with the color ‘” + color + “‘.”);.

When we now write a little test which body looks similar to this:

and compile the whole thing together with the aspect ShapeAspect we will get the following output:

As I already said, an advice is the code to be executed at a join point that has been selected by a pointcut. There exist three types of advices: the before, after and around advice. The before advice executes before the execution of a join point, the after advice after the execution of a join point and the around advice surrounds the join point’s execution. We will now look at each advice in turn.

Before advice:

• Structure:
  before() : <Pointcut> {
  …
  }
• Example:
  before() : call(* MyClass.myMethod()) {
  System.out.println(”about to execute MyClass.myMethod()”);
  }

After advice:

• Structure:
  after() : <Pointcut> {
  …
  }

  after() returning(<ReturnType returnObject>) : <Pointcut> {
  …
  }

  after() throwing(<ExceptionType exceptionObject>) : <Pointcut> {
  …
  }

• Example:
  after() : call(* MyClass.myMethod()) {
  System.out.println(”executed MyClass.myMethod()”);
  }

  after() returning(int result) : call(* int MyClass.myMethod()) {
  System.out.println(”The method MyClass.myMethod() returned ” + result);
  }

  after() throwing(Exception e) : call(* int MyClass.myMethod() throws Exception) {
  System.out.println(”The method MyClass.myMethod() threw the exception ” + e);
  }

• Explanation:
  As you can see is it also possible to capture the result of a method call or the exception the method threw. You can deal with these the same way you do with normal arguments/parameters.

Around advice:

• Explanation:
  The before and after advice are quite simple. But the around advice will need a little more explanation.
  If you do not explicitly call the method proceed() in the around advice the originally called method won’t be executed. The method will then just be bypassed. When calling proceed() you must pass the same number and types of arguments as collected by the advice. The proceed() method will also return the result of the method call.
  Another thing you have to do is specifying the return type the adviced join point has. If you are not sure what the return type of the join point is because you capture multiple different join points independent of their return type use Object. AspectJ will then automatically adjust the type based on the return type of the particular join point.
• Structure:
  <returnType> around() : <Pointcut> {
  …
  }
• Example:
  int around() : call(* int MyClass.myMethod()) {
  // doSomething
  int result = proceed(); //
  // doAnotherThing
  return result;
  }