Note: The complete sourcecode is available on github here. For just downloading, unzipping and importing the project into Eclipse, press on the github site (detailed instructions below).

Besides the Google Web Toolkit (GWT), there is a nice web application framework for Java-only users called Vaadin.
Out-of-the-box, it has a more polished interface and prettier components than GWT.
I used it in a small application, my experience was very positive, even though I used Vaadin in a non-standard way (periodic asynchronous updating of a component by a infinitely running process), it works very well and there was really good support by the Vaadin team.
Note: This post is not an introduction to Vaadin, I hardly know it myself. A great developer-friendly entry are the sample applications. For more info, there is a step-by-step tutorial and a book for deeper understanding.

Intention

Automated testing of a web application is used in a Continuous Integration Environment. Furthermore, load/stress testing of the web application takes place in a Performance Test setting. A process should monitor logfiles in these test environments and report errors in a web-based report.

Technically, a thread must monitor several logfiles, aggregate these errors in a managed component which must be analyzed by a visualizing component (eg. a automatically refreshing table), which must be accessible from several clients.

So, now with technological annotations…

Technically, a thread must monitor several logfiles (Groovy), aggregate these errors in a managed component (Groovy, JMX) which must be analyzed by a visualizing component (eg. a automatically refreshing table), which must be accessible from several clients (web based, Vaadin).

Ok, lets go.

The “server side components”

The server side just consists of a simple Groovy script:

import javax.management.remote.*
import javax.management.*
import groovy.jmx.builder.*
import java.rmi.registry.LocateRegistry

class ServerState implements Serializable {
    def list=[]
}
def jmxbean = new ServerState()

Thread.start {
    def jmx = new JmxBuilder()
    def beans = jmx.export {
        bean(name: "jmx.builder:type=ExportedObject", jmxbean)
    }
    LocateRegistry.createRegistry(9000)
    jmx.connectorServer(port: 9000).start()
}

def worker = { logfile ->
    println "analyzing ${logfile}"
    logfile.withReader { reader ->
        reader.skip(logfile.length())
        while (true) {
            def line = reader.readLine();
            if (!line) {
                Thread.sleep(1000);
            } else {
                def inner = [:]
                inner["server"] = logfile.name
                inner["ts"]= new Date().toString()
                inner["error"] = line
                jmxbean.getList().add(inner)
            }
        }
    }
}

new File("c:/temp/").eachFileMatch(~/^log.txt.*/) { file ->
    Thread.start worker.curry(file)
}

First, a thread is started that exports the aggregating bean via JMX (it’s so easy in Groovy).
After calling jmx.connectorServer(port: 9000).start(), the bean is available under the JNDI-Name service:jmx:rmi:///jndi/rmi://localhost:9000/jmxrmi to client processes (using the name jmx.builder:type=ExportedObject).
Afterwards, a worker closure is created. Nothing special in there, just the reader.skip(logfile.length()) makes sure the end of the file is used at the beginning (before the monitoring process starts).
The last three lines are quite dense, though. Here, all files matching the pattern (eg, log.txt, log.txt1, log.txt2) are used to create threads which monitor these files. This is easily achieved by using currying, which is described in detail here.
In this case, file is applied and the rest (the partially applicated closure) is submitted to Thread.start, which takes a closure (now with an already defined logfile) as the argument.

Tip: Using the Groovy script

All information necessary to run Groovy in any environment is stated here.
However, there is a really cool way of testing Groovy scripts without any settings, etc. Just JAVA_HOME must be set correctly.

1. Download Groovy, unzip or install to some directory (eg. c:\dev\groovy)
2. Set your JAVA_HOME environment variable to your Java installation (eg. set JAVA_HOME=c:\java\jdk1.6.0_17).
3. Start groovyConsole.exe (in \$GROOVY_HOME\bin). Paste the script there. Run it.

Located in GROOVY_HOME\bin: groovyConsole

groovyConsole in action

The “client side”

Testing with jconsole

jconsole is included in the Java SDK (JAVA_HOME\bin)

The JMX-URL is determined by the Groovy script

Result of calling the exported operation getList()

Creating a web app client with Vaadin

1. Download the Vaadin Eclipse plugin.
2. Download the zipped files (click on ). It’s subproject Vaadin.
3. Create new Vaadin project, choose Vaadin jar (cmp. image) – this post was tested with vaadin-6.2.nightly-20091016-c9216.jar.



4. Delete generated src and Webcontent (!! except WEB-INF/lib !!) directores and copy from downloaded zip.

Structure and Functioning

The JMX-component to connect to Groovy-JMX-server

public class JmxService {

	private JMXServiceURL url;
	private JMXConnector jmxc;
	private MBeanServerConnection mbsc;
	private ObjectName mbeanName;

	private static JmxService INSTANCE;

	private JmxService() {
		try {
			url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9000/jmxrmi");
			jmxc = JMXConnectorFactory.connect(url, null);
			mbsc = jmxc.getMBeanServerConnection();
			mbeanName = new ObjectName("jmx.builder:type=ExportedObject");
		} catch (MalformedURLException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		} catch (MalformedObjectNameException e) {
			e.printStackTrace();
		} catch (NullPointerException e) {
			e.printStackTrace();
		}
	}

	public static JmxService getInstance() {
		if (INSTANCE == null) {
			INSTANCE = new JmxService();
		}
		return INSTANCE;
	}

	public ServerState getServerState() {
		return JMX.newMBeanProxy(mbsc, mbeanName, ServerState.class, true);
	}

}

The table with its on-click-listener is created in pure Java

	private Table initTable(final IndexedContainer container) {
		final Table table = new Table();
		table.setContainerDataSource(container);
		table.setWidth("100%");
		table.setPageLength(PAGE_LENGTH);
		table.setColumnExpandRatio("error", 1);
		table.setSelectable(true);
		final Application self = this;
		table.addListener(new Table.ValueChangeListener() {
			@Override
            public void valueChange(ValueChangeEvent event) {
				Object o = table.getValue();
                if (o != null) {
                	preformattedText = new Label("Here can be sources");
                    preformattedText.setContentMode(Label.CONTENT_PREFORMATTED);
                    self.getMainWindow().addComponent(preformattedText);
            	} else {
                    self.getMainWindow().removeComponent(preformattedText);
                }
          	}
        });
		return table;
	}

The Refresher”pattern” is explained here, the sources are in the repository. All necessary sources are also included in the github sources to this post.

Running the project

You can just start the server-side Groovy script (after configuring the file matching loop at the end of the script corresponding to your system). Afterwards, just start the Vaadin project with “Run on Server”.
Now, you have to change a monitored file (eg. add a line and save the file). If you have chosen “Aktualisierung starten” (ie. start polling for new JMX events) the changed line should appear in the table. You can choose the line (details view is not implemented yet) to display more information. The table scrolls accordingly (the last item is always displayed at the bottom of the table).
The refresh mechanism necessary for polling the JMX state is copied from here.
Note: for real usage, it would be much better to use JMX notification for this use case.

Note: The complete source and necessary jars are available in github here. For just downloading, unzipping and importing the project into Eclipse, press on the github site.
Important: this is a collection of projects, the relevant project for this post is gae-rest-sample and spring3-resttemplate.

Finally I succeeded in getting REST (with the new REST support in Spring 3) done in the Google App Engine.
It wouldn’t be an easy task, but thanks to one brilliant blog post, a forum post and a very helpful JIRA issue, it can be resolved just by searching.

1. The brilliant blog post about Spring REST in general by Eyal Lupu.
   This post is just a rewrite of that one, just adding the GAE-related stuff.
   All details about REST content negotiation and how the Spring MVC works with REST is explained there.
2. The forum post about problems with GAE and XStream.
   This helps to unterstand the reason for the sun.reflect.ReflectionFactory is a restricted class exception when using XStream on GAE.
3. The JIRA issue 566, which investigates the problem in more detail and provides a solution which is valid for at least the usage in this context (note the last entry).

I finally took the snapshot jar attached to the JIRA issue, which works well for the samples in this post. Nevertheless, there might still be difficulties with XStream on the GAE, so be aware.

The client

Eyal Lupu also provides a JSON-Client in his post. The client itself is straightforward – it uses the Spring RestTemplate. The JsonHttpMessageConverter uses Spring’s FileCopyUtils for InputStream String conversion which is quite cool.

Spring RestTemplate:

    RestTemplate restTemplate = new RestTemplate();
    restTemplate.setMessageConverters(new HttpMessageConverter[]{new JsonHttpMessageConverter()});

    JSONObject result = restTemplate.getForObject("http://localhost:8080/users/.js", JSONObject.class);

    JSONArray aresult = result.getJSONArray("payload");
    for (int x=0; x<aresult.length(); ++x) {
        JSONObject currResult = (JSONObject) aresult.get(x);
        System.out.format("%-100s | %s%n", currResult.get("name"), currResult.get("lastLoggedInAt"));
    }

JSON-Unmarshaller:

	@Override
	protected JSONObject readInternal(Class<JSONObject> clazz, HttpInputMessage inputMessage) throws IOException, HttpMessageNotReadableException {
                MediaType contentType = inputMessage.getHeaders().getContentType();
		Charset charset = contentType.getCharSet() != null ? contentType.getCharSet() : Charset.forName("utf-8");
		String stringResult =  FileCopyUtils.copyToString(new InputStreamReader(inputMessage.getBody(), charset));

		JSONObject jObject;
		try {
			jObject = new JSONObject(stringResult);
		} catch (JSONException e) {
			throw new IOException (e);
		}
		return jObject;
	}

Annoyances

Here are some things I don’t understand and I had to work around.
Please comment if you know more about the problem.

1. In the web.xml, the url-pattern has to be / instead of /* (or /rest in the original sample) to get it working in the GAE
2. Usually, I would prefer having the jsp-views in /WEB-INF/*. However, this does not work in GAE (doesn’t find WEB-INF or anything below WEB-INF)

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:

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”)