Continuing the Scala Mashup Series, this post is about a quite important, often used, but also controversial pattern: The Template Method.

In general, there are great explanations of the pattern in Wikipedia and of course in Head First Design Patterns.

Criticism

A very good summary of the Template Method pattern especially in comparison to the Strategy pattern is on stackoverflow.com:

The Template pattern does compile-time algorithm selection by subclassing.
The Strategy pattern does run-time algorithm selection by containment.

Example

Imagine you want to arrange a dinner. The entire algorithm for arranging a dinner is predefined:

1. Invite your guests
2. Go shopping
3. Clean your fridge to provide enough space
4. Prepare the meal
5. Server the meal
6. Wash the dishes

Now, some parts of this algorithm (which in its entirety is called arrange) are fixed (invariant parts). Other parts are highly dependant on the meal you want to prepare (variant parts).
In Template Method, the algorithm itself is described in a public accessible method, eg. arrange(), which combines and calls the variant and invariant methods. The invariant methods are implemented in the abstract super class. The variant parts are implemented in the concrete classes, eg. BratwurstDinner, which implements the concrete way to do shopping for the BratwurstDinner, as well as the preparation of the Bratwurst itself.
The important part is the compile-time binding – the implementing, concrete classes cannot change their implementation during runtime.
This makes the Template Method almost ideal for framework creation, when you want to provide abstract algorithms with certain concrete implementations (think of abstract database layers, with an algorithm which cares for opening & establishing connections, handles exceptions and cleans up nicely after doing … the variant part, which is implemented in the concrete classes).

Here is the dinner example using the Template Method pattern

Here is the dinner example using the Strategy pattern

There are two clever blog posts, one about disadvantages of the Template Method pattern, and one mentioning a possible alternative in languages with first class functions like Scala.

Language comparison: Java, Scala, Spring

We will happily leave out the Java example, since it is just too obvious. In the Wikipedia article a sample is given, together with the class diagram it should be pretty obvious how Template Method is implemented in Java. The only thing to keep in mind is to set the super class abstract, as well as the variant methods – which are then implemented (using @Override) in the concrete classes.

Scala

In Scala there are is the intuitive way of implemeting the Template Method, analogous to Java:

abstract class DinnerEvent {

  def arrange: Unit = {
    makeGuestList
    doShopping
    cleanFridge
    prepareMeal
    serveMeal
    washDishes
  }

  def prepareMeal: Unit
  def doShopping: Unit

  def makeGuestList: Unit = {
    println("making guest list...")
  }

  def cleanFridge: Unit = {
    println("cleaning fridge...")
  }

  def serveMeal: Unit = {
    println("serving meal...")
  }

  def washDishes: Unit = {
    println("washing dishes...")
  }

}

trait TurkeyDinner {

  def doShopping: Unit =  {
    println("...buying turkey")
  }

  def prepareMeal: Unit =  {
    println("...preparing turkey")
  }

}

object TemplateMethod {

  def main(args:Array[String]) = {
    val dinner = new DinnerEvent with TurkeyDinner
    dinner.arrange
  }

}

However, in languages with first class functions, it is too tempting to use the Strategy pattern:

class DinnerEventWithStrategy(shoppingStrategy: => Unit, preparingStrategy: => Unit) {

  def arrange: Unit = {
    makeGuestList
    shoppingStrategy
    cleanFridge
    preparingStrategy
    serveMeal
    washDishes
  }

  def makeGuestList: Unit = {
    println("making guest list...")
  }

  def cleanFridge: Unit = {
    println("cleaning fridge...")
  }

  def serveMeal: Unit = {
    println("serving meal...")
  }

  def washDishes: Unit = {
    println("washing dishes...")
  }

}

object Closure {

  def turkeyShoppingStrategy: Unit = {
    println ("...shopping turkey strategy")
  }

  def turkeyPreparationStrategy:Unit = {
    println ("...preparing turkey strategy")
  }

  def main(args:Array[String]) = {
    val dinner = new DinnerEventWithStrategy(turkeyShoppingStrategy, turkeyPreparationStrategy)
    dinner.arrange
  }

}

So, you should choose wisely, both patterns definitely have their scope of application – just keep in mind that Strategy also uses composition over inheritance, which is always a good advise.

…and what about Spring?

This is interesting, Spring uses the Template Method a lot – and many think it is one of their greatest strengths.
But wait … the Template Method pattern? Not really. The Spring Framework templates in fact are not implementing the Template Method pattern, even if it feels this way.
Let’s examine a small usage example of Spring’s JdbcTemplate:

package com.commons.sample.dao;

import java.util.List;

import org.springframework.jdbc.core.simple.ParameterizedBeanPropertyRowMapper;
import org.springframework.jdbc.core.simple.SimpleJdbcDaoSupport;

public class JdbcSimpleDao extends SimpleJdbcDaoSupport implements SimpleDao {

	final static String single	= "select id, name from test where id = ?";
	final static String list 	= "select id, name from test"; 

	public Simple getSimpleById(int id) {
		return getSimpleJdbcTemplate().queryForObject(single,
				ParameterizedBeanPropertyRowMapper.newInstance(Simple.class), id);
	}

	public List<Simple> getSimples() {
		return getSimpleJdbcTemplate().query(list,
				ParameterizedBeanPropertyRowMapper.newInstance(Simple.class));
	}

}

What is happening here? Even though the class extends SimpleJdbcDaoSupport, it would not have to.
The Method query(…) takes the SQL and a ParameterizedBeanPropertyRowMapper.newInstance(Simple.class), which defines a row mapper that creates an object of class Simple – this certainly describes a strategy. So, even the so-called Spring Templates actually uses the Strategy pattern.

Summary

The Template Method is a powerful pattern. Use it if you create a framework, since you can inject certain functionality in the implementing classes at compile time, which let the user of your framework extend it easily, but in a controlled and “traceable” way. For Java, it is a natural way to enable users of your classes to extends the functionality at certain points.
In languages with first-order functions (or closures), like Scala, it might feel more natural to use the Strategy pattern instead. However, keep in mind that the patterns are not completely identical.

In the last post, I created a prototype with some technologies which were new to me, especially Gaelyk.

As it turned out, the prototype behaved quite differently in my local system and when deployed in the Google App Engine. What seems really strange to me is that even after all five number series had been cached, every 3-4th request took quite long, at least locally. In the deployed version, this seemed to be different and not too slow (even though I suppose a pure Java version would be significantly faster).

Now, how can I test without too much trouble if the deployed site is “just fast enough”?
Having looked around quite some time, Grinder looked most promising to me, with respect to easy of usage and features.

Preparation

Download Grinder and Jython 2.2.1 – it must be this version, not the current 2.5.x – this just does not work.

Install Jython.

Create grinder.properties and grinder.py – they can go in any directory, the most simple usage will be in the grinder/lib directory:

grinder.properties (change directory accordingly):

grinder.runs=0
grinder.threads=10
grinder.processes=1
grinder.jvm.arguments=-Dpython.home=/dev/jython2.2.1

grinder.py

# A simple example using the HTTP plugin that shows the retrieval of a
# single page via HTTP. The resulting page is written to a file.
#
# More complex HTTP scripts are best created with the TCPProxy.
import string
from net.grinder.script.Grinder import grinder
from net.grinder.script import Test
from net.grinder.plugin.http import HTTPRequest

test1 = Test(1, "Request resource")
request1 = test1.wrap(HTTPRequest())
log = grinder.logger.output

class TestRunner:
    def __call__(self):
	grinder.statistics.setDelayReports(1)
        result = request1.GET("http://localhost:8080/data.groovy")
	log(result.getText())
	if string.find(result.getText(), "counter") < 1:
	    grinder.statistics.forLastTest.setSuccess(0)
        # result is a HTTPClient.HTTPResult. We get the message body
        # using the getText() method.

Usage

Now you can start the Grinder console with:
java -cp grinder.jar net.grinder.Console

Afterwards, start the Grinder agent with:
java -cp grinder.jar net.grinder.Console

Now, you must sync the data first, as shown in the screenshot. Afterwards, just start the tests.

According to the config, the agent runs indefinitely in 10 Threads. The site in the Jython script is called and in the resulting page, the expression counter is searched. If it is not present, the test fails. You can verify this by stopping the server, it will start increasing the failure counter immediately.

All in all, we have a very easy load test with very few lines of code.

As a result, the remote Google App Engine runs much more stable, so I just presume that the memcache implementation of the local Google App Engine server is not as good/stable as the remote one. But this is just a guess.

However, be careful with Gaelyk besides from using it for prototypes, because if the site is not called continuously, it kind of fells asleep really fast (some minutes) and needs its time for wakeup, which is quite annoying. I just don’t know what causes this, Gaelyk or the GAE.
You can verify this by just loading the Gaelyk home page. The first call often really feels kind of slow.

Note: Github available here. It works best with the current SpringSource Tool Suite.

Having had evening to spare, together with a colleague I came up with the following nano-project:

Write a prototype for creating a chart from some series of numbers, which is hosted in a cheap cloud.

So this brings me to: “Write a prototype (Groovy) for creating a chart (Google Chart API) from some series of numbers (taken from spreadsheets of Google Docs), which is hosted in a cheap cloud (Google App Engine).”
Some day, I will have to fix this Google addiction – however, Groovy is not affiliated to Google at all.

Evaluation of Frameworks

Wanting to combine Groovy and the Google App Engine, I immediately came across two different frameworks, the almighty and ubiquitous Grails and the much more pragmatic Gaelyk.
Since for this purpose Gaelyk is more than enough and because I wanted to try it, I used this for prototyping. By downloading the sources from Github, the typical Gaelyk project setup can be concluded if analyzed together with the information given in the Gaelyk tutorial – it’s quite easy.

The data (about 100-1000 random numbers between 5000 to 6000) should come from a web based, private (authorization-based) available data source – even though many possibilities exist, I chose Google Docs for two reasons:

1. Easy creation of “some” random numbers
2. Authorization based on Google Authorization
3. Access class already exists (cmp. this post)

The last important feature should be the creation of a chart. Here, really a lot compelling solutions exist. Mainly, there are three different ways to realize Chart creation:

1. Java based, eg. JFreeChart
2. Javascript based, eg. JQuery plugin flot
3. Pure Web based, eg. Google Chart API

Since I want to have it simple & easy, the third option is really great for this use case. A chart can very easily be created, compare this, which is rendered dynamically:

which is:

http://chart.apis.google.com/chart?chxl=0:||1:|&cht=lc&chxt=x,y&chs=500x150&chco=0077CC&chm=B,E6F2FA,0,0,0&chd=t:5563.0,5807.0,5096.0,5898.0,5306.0,5944.0,5932.0,5510.0,5088.0,5791.0,5039.0,5145.0,5459.0,5395.0,5997.0,5075.0,5587.0,5760.0,5561.0,5719.0,5108.0,5339.0,5321.0,5686.0,5213.0,5987.0,5228.0,5670.0,5594.0,5292.0,5909.0,5616.0,5978.0,5375.0,5504.0,5558.0,5840.0,5233.0,5947.0,5028.0,5592.0,5992.0,5020.0,5991.0,5953.0,5471.0,5243.0,5784.0,5472.0,5801.0,5652.0,5700.0,5183.0,5949.0,5809.0,5426.0,5130.0,5394.0,5919.0,5741.0,5134.0,5402.0,5801.0,5567.0,5478.0,5740.0,5563.0,5677.0,5346.0,5020.0,5243.0,5137.0,5787.0,5241.0,5351.0,5834.0,5630.0,5542.0,5238.0,5242.0,5312.0,5642.0,5424.0,5988.0,5796.0,5912.0,5599.0,5567.0,5832.0,5559.0,5760.0,5061.0,5629.0,5951.0,5095.0,5585.0,5602.0,5686.0,5562.0,5700.0,5267.0,5656.0,5757.0,5023.0,5498.0,5935.0,5650.0,5807.0,5345.0,5080.0,5919.0,5308.0,5316.0,5076.0,5154.0,5399.0,5537.0,5923.0,5968.0,5973.0,5528.0,5640.0,5097.0,5369.0,5374.0,5248.0,5955.0,5243.0,5949.0,5126.0,5659.0,5010.0,5473.0,5012.0,5536.0,5274.0,5115.0,5809.0,5212.0,5400.0,5550.0,5274.0,5931.0,5762.0,5343.0,5655.0,5434.0,5981.0,5844.0,5277.0,5823.0,5905.0,5741.0,5168.0,5057.0,5956.0,5841.0,5804.0,5421.0,5933.0,5667.0,5171.0,5083.0,5322.0,5410.0,5459.0,5092.0,5678.0,5401.0,5817.0,5526.0,5663.0,5753.0,5802.0,5289.0,5917.0,5020.0,5372.0,5993.0,5023.0,5773.0,5469.0,5681.0,5442.0,5736.0,5552.0,5678.0,5493.0,5758.0,5726.0,5713.0,5103.0,5201.0,5435.0,5583.0,5318.0,5501.0,5076.0,5004.0&chds=4000,7000

Now, was this easy?

Preparation/Implementation

First, the Groovy file which dispatches the request is as follows (must go to the groovy folder):

import java.net.URLConnection;

def labels = ["A", "B", "C", "D", "E"]
int ivalue = new Random().nextInt(5);

String link;
if (memcacheService.get(labels.get(ivalue)) == null) {
	def ts = new com.commons.gse.TestSheets();
	link = ts.getData(labels.get(ivalue));
	memcacheService.put(labels.get(ivalue), link)
} else {
	link = memcacheService.get(labels.get(ivalue))
}
request.setAttribute ('counter', com.commons.gse.TestSheets.counter++)
request.setAttribute ('appendix', link)
forward '/data.gtpl'

The interesting part is the usage of the predefined object memcacheService which makes it possible to just use Google App Engine’s memcache without having to deal with creation, exception handling, etc.
One of five (“A-E”) cached number series is used. If no cache for the character is found, the number is extracted from a speadsheet called data in Google Docs (see screenshots below).
After having calculated or retrieved the numerb series from the cache, the values (which is the complete link with the numbers included) are put into the ServletRequest (in this case the predefined object request). Finally, the request is dispatched to the view, a Groovy template (data.tgpl).

<html>
<head/>
<body>
  <span>counter:<%= request.getAttribute('counter') %></span>
  <form>
    <input type="button" value="Reload" onClick="window.location='/data.groovy'">
  </form>
  <img src='<%= request.getAttribute('appendix') %>'/>
</body>
</html>

A final note: if you want to use this from Github, you will have to change the Google authorization data in TestSheets.java (which is completely left out here, but is described here).

Here is the setup of the Google Docs spreadsheets:

Running

If you have installed the SpringSource Tool Suite, you can just import the Eclipse project and choose “Run as…/Web Application”. The local server should be startet. Afterwards, you can call http://localhost:8080/data.groovy.

Note: Be sure to change the username/password combination in TestSheets.java

Up to now, I identified three different kinds of factory patterns, which are similar to each other.

Simple, but powerful: The Simple Factory

The simple factory in Java is implemented as a static method, which returns a object of a certain type. This object can be newly created or a singleton (in contrast to object creation with constructors, which create new objects always).

Advantages [taken from Effective Java (2nd Edition)]

1. Factory methods have names

Constructors differ only by signature. With factory methods, the method itself can describe the kind of object created.

2. Factory methods decide what kind of objects are created

With factory methods, newly created objects can be returned as well as singletons.

3. Factory methods can return objects of any subtype

Depending on the submitted arguments, the method can decide to return subtypes of the return type (see example below).

4. Verbosity of creating parameterized type instances is reduced

Redundant specification of the form Map map = new HashMap() is not necessary with factory methods, since the compiler is able to infer the type by type inference.

Disadvantages:

1. Factory methods do not favor inheritance

Returned (non-public) types of factory methods cannot be subclasses (if they have no public or protected constructors).

2. Factory methods cannot be identified as creational methods as easy as constructors

This can be leveled by using conventions, eg. valueOf, getInstance, of depending on the context.

public class Factory {

    public static Item createItem( Object decideUpon ) {

        int itemType = figureOutItemType( decideUpon );

        switch( itemType ) {
            case Constants.Type1:
                return new Type1();
            case Constants.Type2:
                return new Type2();
            // etc.
        }
    }
}

And now in Scala:

object Factory {

  def createItem( decideUpon:String ):Item = decideUpon match {
    case "type1" => new Item1Type
    case "type2" => new Item2Type
    case _ => error("Unknown option.")
  }

}

The real Factory Method

The Factory Method is used to create several concrete objects of one abstract class.
In contrast to the Simple Factory described above, the factory itself is subclassed, therefore a concrete factory which creates concrete classes can be created depending on the context.

public abstract class Factory {

    public abstract Item createItem();

}

public class Item1Factory extends Factory {

    public Item createItem() {
        return new Type1();
    }

}

public class Item2Factory extends Factory {

    public Item createItem() {
        return new Type2();
    }

}

In Scala, the code is almost the same, is might just be simplyfied by the use of pattern matching (not equal to the Java version).

trait Factory {  

  def create( decideUpon:String ): Item

}

object Item1Factory extends Factory {

  def create(): Item = instanceType match {
    case "type1" => new Type1Item
    case _ => error("Unknown option.")
  }

}

Last, not least: Abstract Factory

In short, an Abstract Factory is used to create families of related objects.
The creation methods inside the Abstract Factories are usually implemented as Factory Methods.

This is the first post of a series of mashup post which try to combine the following books in a Scala way:

• Head First Design Patterns
• Effective Java, Second Edition
• Programming in Scala

Having completely read the Head First Design Patterns and (partly) the second edition of Effective Java, I highly recommend those two books to Java developers.
I am right now studying Programming in Scala and I am not sure if I can recommend it.

The mashup will try to find common patterns in Effective Java and Head First and try to related these patterns to the Scala world. Hopefully, this approach will represent a different way to learn Scala – highly Java focused and with mixing design patterns and effective programming style in.

It’s really easy to create a MBean, export it with the platform MBean server and access the bean with Groovy.
Here’s how (it’s more or less an extended rewrite of this post).

The main trick is to implement ApplicationContextAware, which let Spring call the setApplicationContext method with the prepared application context (not tried, could be even shorter: is autowiring with the type “ApplicationContext” possible as well?)

Java part

The ManagementFactory lets you register your MBean in the platform MBean server (used to serve the application context).
Important: The easiest way to access the MBean remotely is by providing -Dcom.sun.management.jmxremote.port=6666 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false as System parameters (VM arguments in Eclipse) – obviously, this is not very secure.

package com.commons.blog;

import java.lang.management.ManagementFactory;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.management.InstanceAlreadyExistsException;
import javax.management.MBeanRegistrationException;
import javax.management.MalformedObjectNameException;
import javax.management.NotCompliantMBeanException;
import javax.management.ObjectName;

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class AppCtxGlobalExporter implements AppCtxGlobalExporterMBean, ApplicationContextAware {

	private ApplicationContext appCtx;

    public AppCtxGlobalExporter() {}

	public void setApplicationContext(ApplicationContext appCtx) throws BeansException {
		this.appCtx = appCtx;
    	initMBeanServer();
	}

	private void initMBeanServer() {
		try {
			ManagementFactory.getPlatformMBeanServer().
				registerMBean(this, new ObjectName("jmxsample:type=AppCtxGlobalMBeanExporter"));
		} catch (InstanceAlreadyExistsException e) {
            Logger.getLogger(AppCtxGlobalExporter.class.getName()).log(Level.SEVERE, null, e);
		} catch (MBeanRegistrationException e) {
            Logger.getLogger(AppCtxGlobalExporter.class.getName()).log(Level.SEVERE, null, e);
		} catch (NotCompliantMBeanException e) {
            Logger.getLogger(AppCtxGlobalExporter.class.getName()).log(Level.SEVERE, null, e);
		} catch (MalformedObjectNameException e) {
            Logger.getLogger(AppCtxGlobalExporter.class.getName()).log(Level.SEVERE, null, e);
		} catch (NullPointerException e) {
            Logger.getLogger(AppCtxGlobalExporter.class.getName()).log(Level.SEVERE, null, e);
		}
	}

    public String[] getBeanNames() {
    	return appCtx.getBeanDefinitionNames();
    }

}

with the interface:

package com.commons.blog;

public interface AppCtxGlobalExporterMBean {

    String[] getBeanNames();

}

Here the main class:

package com.commons.blog;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AppCtxRegistry {

	public static void main(String[] args) {
		ApplicationContext app = new ClassPathXmlApplicationContext("beans.xml");
		SampleBean sample = (SampleBean) app.getBean("sample");
		System.out.println(sample);
		while(true) {
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}

}

the sample bean is left out, it’s not important and could even be empty.
The important part is the applicationContext.xml, the bean which implements ApplicationContextAware must just be instantiated, the Method setApplicationContext is called with the appropriate appcontext on startup.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
   "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
  <bean class="com.commons.blog.AppCtxGlobalExporter"/>

  <bean id="sample" class="com.commons.blog.SampleBean"/>
</beans>

Now comes the fun (Groovy!) part:

import javax.management.ObjectName
import javax.management.remote.JMXConnectorFactory as JmxFactory
import javax.management.remote.JMXServiceURL as JmxUrl

class JmxClient {

    def jmx() {
        def serverUrl = 'service:jmx:rmi:///jndi/rmi://localhost:6666/jmxrmi'
        def server = JmxFactory.connect(new JmxUrl(serverUrl)).MBeanServerConnection
        def mbean = new GroovyMBean(server, "jmxsample:type=AppCtxGlobalMBeanExporter")
       	mbean.BeanNames.each {
        	println it
        }
    }

    public static void main(String[] args) {
        new JmxClient().jmx()
    }

}

Being quite a fan of Groovy (which also is related to Spring in some way), I nevertheless experimented with Scala a bit.
Trying not to follow the current hype about this language, I mainly wanted to check a higher-level (meaning higher than Java), typed language and like Scala, even though to me there seems to be too much magic in it to overcome the non-dynamic aspect (this might not be formally correct, but hopefully understandable).

Due to this non-dynamic aspect, many things which are highly praised in Scala seem clumsy compared to Groovy. Just compare the granted-better-than-Java XML-handling in Scala with the even-much-better XML-handling in Groovy.
Of course, my IDE will never be able to code complete the Groovy variant – however, currently, the Scala Eclipse Plugin does it neither.

So, I bought the book “Programming in Scala”, which is good, but there are certain parts which are not too well described, one being the difference between “receive” and “react”.
I did it understand only after trying out myself (see below) and reading this post.
Once again, stackoverflow.com has been very useful to me (I just know the site for about 2-3 months and found useful information there several times).

So, I wanted to try if I can validate the different behaviour (which is in short that receive blocks a Thread and react returns immediately and is not bound to a particular Thread – but there are better explanations out there).

Preparation

I wanted to check the behaviour by forcing Scala to instantiate just one thread in the thread pool. This can be done by setting two system properties:

-Dactors.maxPoolSize=1
-Dactors.corePoolSize=1

this can be concluded by the Actors sources.

Running

I used two different objects:

import scala.actors._
import scala.actors.Actor._

object Reactor extends Actor {

	def act() {
		while(true) {
			receive {
				case (x: String, actor: Actor) => println("received:" + x)
				actor ! (x, self)
			}
		}
	}
}

and the Runner:

import scala.actors._
import scala.actors.Actor._

object Runner extends Actor {

	def act() {
		while(true) {
			receive {
				case (string: String, actor: Actor) =>
					println("got: " + string)
					actor ! ("hello", self)
			}
		}
	}

	def main(args : Array[String]) : Unit = {
			Runner.start()
			Reactor.start()
			Reactor ! ("hello", Runner)
	}	

}

Starting the application with this parameters just freezes it immediately. We need at least a threadpool of two threads. With these two threads, the application starts and the result with visualvm is like this:

Switching while(true) to loop and receive to react results in one sharing thread, which means the size can be max=1, core=1 and the application runs like this:

Which look like it should – the react does not block the thread, therefore one “shared” thread is enough – the react of each actor is then “attached” to the main thread.

No real news here, just another example for Spring and Groovy in a simple web project.

Github for server version is here.
Github for client version is here.

What does it do?

We needed a simple Request/Response Mock for SOAP Web Services. Since the real sending component uses EJB and Weblogic t3-protocol specific stuff, I wanted to decorate this component.
The simplest way seemed to create an own endpoint, which accepts the SOAP web service requests, searches for templates based on the payload-root-element and evaluates the determined template (which itself is a Groovy template).

How does it work?

Quite straightforward. If a directory with the file template.groovy and the name of the root element of the payload exists, the template is loaded and evaluated with the input data and finally returned by the DispatcherServlet.
Spring MVC is used, however it was not necessary for this little sample.
The most interesting part is the injection (with @Autowired) of the Groovy script (which resides in src/main/resources/, which is not really correct).

<!-- this is really important to start the annotation processing in Spring -->
<context:annotation-config/>

<!-- the controller is instantiated, via @Autowired the Groovy Script is set -->
<bean id="RequestMockController" class="com.mock.sample.RequestMockController"/>

<!-- local repository (must be changed most likely) -->
<bean id="localRepo" class="java.lang.String">
   <constructor-arg value="c:/temp/repo/"/>
</bean>

<!-- instantiate Groovy as a Spring bean -->
<lang:groovy id="xml" script-source="classpath:XmlToolImpl.groovy"/>

IMPORTANT: to be able to use Groovy-Spring beans, the Groovy object should implement a Java interface (which is then used in the Java code).

How do I test it?

Use the client code with the parameters supplied in the README.
The request could look like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wss="http://wsssample.com.mock.sample">
  <soapenv:Header/>
    <soapenv:Body>
      <wss:getString>
        <wss:name>?</wss:name>
      </wss:gettring>
   </soapenv:Body>
</soapenv:Envelope>

For this request to succeed, the file REPO/getString/template.groovy must exist (see resources).

Specials

In the sample, there is one special behaviour, which requires two passes – if the template returns something like “>redirect”, the request is redirected to the new file (this works one time only and is just included to easy the “dispatching or controller pattern”)

After having experimented with Eclipse Galileo and the now included Memory Analyzer in the last post, I came across BTrace, which very nicely fits to the tool chain for analyzing Memory Leaks and/or performance problems in applications.

Continuing the problem analysis from the last post, after having found out the resulting object for the memory leak (leakingSet), it would be interesting to find out where the objects are inserted.

Preparation

1. Download visualvm
2. Install the BTrace plugin as described here
3. Extend the object insertion with a Thead.sleep (I used 100ms)
4. Start the sample application

Usage

1. Start visualvm and search for the started application PID
2. Start tracing…
3. Install the following script

import com.sun.btrace.annotations.*;
import com.sun.btrace.AnyType;
import static com.sun.btrace.BTraceUtils.*;

@BTrace public class TraceLeakingSet {
    @OnMethod(
        clazz="+java.util.Set",
        method="add"
    )
    public static void method(AnyType[] arg) {
        print(strcat("entered ", name(probeClass())));
        print(strcat(".", probeMethod()));
        println(strcat(" with argument ", str(arg[1])));
        jstack();
        println();
    }
}

The script will log every call to the method “add” on all subclasses of “java.util.Set” (that’s the “+”). The submitted argument is included in the first index of the AnyType array.
probeClass and probeMethod display the called class and method, jstack() displays the real stack trace. This is most useful, together with the display of class, method and argument.

Sample output is as follows:

BTrace code successfuly deployed
===========================================================
entered java.util.HashSet.add with argument scopedTarget.scopetest
java.util.Collections$SynchronizedCollection.add(Collections.java:1577)
org.springframework.beans.factory.support.AbstractBeanFactory.markBeanAsCreated(AbstractBeanFactory.java:1257)
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:256)
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:175)
org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33)
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:657)
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:608)
com.commons.Scopetest$$EnhancerByCGLIB$$3824588a.uniqueCode()
com.commons.Tester.start(Tester.java:25)
com.commons.Tester.main(Tester.java:14)

entered java.util.HashSet.add with argument -841086979
com.commons.Tester.start(Tester.java:25)
com.commons.Tester.main(Tester.java:14)


So there are two alternating locations where add is called on Set and it’s subclasses, one location is in Spring itself (which is interesting but of no concern for the problem) and – of course – the line where the object is added in the start method. This is the location we are looking for – the question would be why so many objects are added with different arguments (instead of always the same argument with singleton instead of prototype usage).

So, BTrace is very easy to use and very useful for tracking problems in running systems with very low overhead and low intrusion (there is actually no change at the deployed code necessary).

The source can be downloaded here. The Spring libraries have to be added manually to the local maven repo (compare this.) The pom is inspired by this post.

I wanted to play with Eclipse Galileo and the Memory Analyzer (MAT), which I used successfully some time ago to identify possible memory leaks.

Using an old example, I construed a case where instead of using a singleton, accidentially a prototype is used (once again a nice sample for Spring’s capabilities – changing one line changes the behaviour completely).

<?xml version="1.0" encoding="UTF-8"?>
<beans [...]>

<!-- using is the "correct" singleton pattern
     <bean id="scopetest" class="com.commons.Scopetest">
     </bean>
-->

<!-- using is the "leaking" prototype pattern
     <bean id="scopetest" class="com.commons.Scopetest" scope="prototype">
         <aop:scoped-proxy/>
     </bean>
-->

     <bean id="testclass" class="com.commons.Testclass">
     	<property name="scopetest" ref="scopetest"/>
     </bean>

</beans>

What’s the difference? Let’s have a look at the main class:

Testclass testclass = (Testclass) app.getBean("testclass");
for (; i < 1000000; i++) {
     Scopetest proxy = testclass.getScopetest();
     leakingSet.add(proxy.uniqueCode());
}
System.out.println("size: " + leakingSet.size());

Using a singleton, the uniqueCode is always the same (I did not use hashCode since it collides with the Proxy hashCode), which leads to a Set with just one object (the uniqueCode of the singleton – which is always the same).
Using the prototype, the class is proxied by cglib and each call to uniqueCode() creates a new Scopetest object, each has a timestamp-based uniqueCode – therefore each object (the uniqueCode-Integer) is added to the Set.

As being said, this is highly construed, however, if you forget to change the object type from prototype to singleton somewhere in your application, you might experience a non-expected behaviour (eg. 1000000 objects instead of one).

How can this be found with Eclipse MAT?

Preparation

First, Eclipse MAT has to be installed (anybody knows why?):

Afterwards, the sample application is started and a heap dump is taken. There are several options for doing this, I used jvisualvm.

Usage

Back in Galileo, the heap dump can now be opened with Eclipse MAT (after opening the MAT Perspective):

Using the generated report, the source of the memory leak is quite easy to find – it is immediately identified as a “suspect” automatically by the “Leak Suspect Report”. Even the correct name of the private member (the Set with the 1000000 objects) is shown (leakingSet), which makes pinpointing the causing object an ease.