Configuring Maven Mirrors

Configuring a Maven mirror might be a good idea for example when

  • You live in Europe and the UK mirror is faster for your
  • is experiencing troubles

It was only yesterday when was down that I learned how to configure mirrors for Maven: Simply add the few lines below to your .m2/settings.xml:

      <name>UK Central</name>
Posted in Java, Maven | Leave a comment

Masquerade Service Simulator Released

A first version of Masquerade Service Simulator has been released. Masquerade is a configurable Service Simulator that returns simulated responses for service requests.

Service stubs can easily be implemented using Masquerade. Simply run Masquerade standalone using its embedded Jetty server or deploy it to an application server (e.g. Tomcat) of your choice, and configure your simulations using its web interface.

Service simulation is useful for example when

  • Providing a service stub for integration or regression tests
  • Doing functional tests against a system that is not (yet) available
  • Providing a stub for functionality that is yet to be implemented in an agile project

Continue reading

Posted in Java, Masquerade, Testing | 1 Comment

Vaadin Widgetset Compilation with Maven

Joram has written an interesting post on how to avoid having Maven recompile the Widgetset for a Vaadin project with every build:

Our continuous integration turnaround time for Vaadin projects has dropped to a few seconds without the GWT compiler overhead, really helpful!

Posted in Java, Maven, Vadiin | Leave a comment

Maven, GWT and ECJ

When compiling a GWT webapp with the GWT Maven Plugin, you might encounter an exception such as

java.lang.NoSuchFieldError: warningThreshold

The reason is having ECJ in your classpath with a version different from what GWT includes. Unfortunately, GWT’s version is not repackaged and thus clashes with other versions. The quick fix is setting the gwtSdkFirstInClasspath configuration option for the gwt-maven-plugin (available since 2.1.0-1, see this issue):

Posted in Eclipse, Java, Maven | 6 Comments

Tomcat not reloading Vaadin App’s View when running in Eclipse

Ever had the problem that changes to a Vaadin App’s UI were not reflected in the runtime when running and deploying to a Tomcat in Eclipse, even after reloading the app? Vaadin stores views in the Session, and a default Tomcat installation will use a persistent Session Manager. Sessions are recreated after the app has been reloaded when using the same browser with the same session key, and the stale view will be loaded from the session.

The solution is simple: In your context.xml (either in Tomcat’s conf dir, or in the Servers project in Eclipse), locate these lines and do what they say:

    <!-- Uncomment this to disable session persistence across Tomcat restarts -->
    <Manager pathname="" />
Posted in Eclipse, Java, Vadiin | Leave a comment

Eclipse Plugin for Concordion

I’ve released a new Eclipse Plugin for editing Concordion Specifications. Concordion is a cool integration testing framework, check out the tutorial if you’re new to Concordion.

The plugin can be installed from the update site as described on the Project Page on Google Code. A good way to keep up-to-date on new plugin releases is to follow the Ohloh Journal, source code is in the Repo on github.

Posted in Concordion, Eclipse, Java, Testing | Leave a comment

Adding Plug-Ins To Your Application With Spring

Spring’s classpath scanning support can be leveraged to easily implement an application that supports plugins to be added.

One method would be to simply scan a specific package (for example org.example.myapp.plugin for beans annotated with @Component, and add them to your application context. This has some disadvantes though:

  • If plugins use annotation-based dependency injection internally, that might clash with your context as all plugin beans will end up in your application’s context
  • It is a very unspecific way to load plugin classes. You’ll need to document very thoroughly what kind of plugin interface your application provides.

It’s probably a better idea to provide a specific interface for your extension points, and then allow plugins to implement them. In this article, I’ll describe a way to achieve this with Annotations and Spring. Suppose your extension point interface looks like this:

public interface ProviderPlugin {
    Resource provide();

The class PluginLoader introduced below will then allow you to implement your plugin like this:

public class MyProviderPlugin implements ProviderPlugin {
    public Resource provide() { ... }

As you can see, all plugins are annotated with a specific annotation, and implement one or more of the extension point interfaces. A plugin annotation is meta-annotated with Spring’s @Component, which allows us to discover and instantiate the plugin using classpath-scanning and a Spring application context.

public @interface MyAppPlugin {

The PluginLoader class contains the plugin lookup and instantiation logic. It is parametrized with the plugin annotation type and the base package to search for plugins:

public class PluginLoader {
    private final Class<? extends Annotation> pluginAnnotationType;
    private final String pluginBasePackage;
    private ListableBeanFactory context;

     * @param pluginAnnotationType The {@link Annotation} for plugin descriptor types
     * @param pluginBasePackage Base package to look in for plugins
    public PluginLoader(Class<? extends Annotation> pluginAnnotationType, 
            String pluginBasePackage) {
        this.pluginAnnotationType = pluginAnnotationType;
        this.pluginBasePackage = pluginBasePackage;

Most of the work is done in the loadContext() method. Here, all plugins annotated with your plugin annotation are instantiated into an AnnotationConfigApplicationContext:

    private void loadContext() {
        if (context == null) {
            // Create a parent context containing all beans provided to plugins
            // More on that below in the article...
            GenericApplicationContext parentContext = 
                new GenericApplicationContext(providedBeans);

            // Create the annotation-based context
            AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
            // Scan for classes annotated with @<PluginAnnotaionType>,
            // do not include standard Spring annotations in scan
            ClassPathBeanDefinitionScanner scanner = 
                new ClassPathBeanDefinitionScanner(context, false);
            scanner.addIncludeFilter(new AnnotationTypeFilter(pluginAnnotationType));
            scanner.scan(pluginBasePackage );
            this.context = context;

The method getPluginDescriptors() returns all plugin beans in the context that implement a specified interface:

    private static <T> Collection<T> getPluginDescriptors(ListableBeanFactory context,
            Class<T> pluginDescriptorType) {
        return context.getBeansOfType(pluginDescriptorType).values();

The getPlugins() method will call loadContext() to find and instantiate all plugins if necessary, and return a collection of plugin instances:

     * Returns all plugins annotated with the annotation specified in the constructor,
     * and returns all instances having type T. This method can be called multiple times
     * for the same loader if you support multiple plugin descriptor types. The plugin
     * scan will be done only once.
     * @param <T> Plugin descriptor interface type
     * @param pluginDescriptorType Plugin descriptor interface class
     * @return A {@link Collection} of all plugins implementing the specified plugin interface type
    public <T> Collection<T> getPlugins(Class<T> extensionPointType) {
        return getPluginDescriptors(context, extensionPointType);

What if your plugins require access to beans in the context they are loaded in? For example an application-provided DataSource, or some sort of resource manager? To achieve this, PluginLoader needs a provideBean() method that allows the hosting application to provide bean instances to plugins:

     * Provide beans available to plugins.
     * @param beanName Bean name
     * @param bean Instance
    public void provideBean(String beanName, Object bean) {
        if (context != null) {
            throw new IllegalStateException(
                "provideBean must be called before loadContext/getPlugins");
        providedBeans.registerSingleton(beanName, bean);

Plugins can then reference these beans:

public class SomePlugin implements MyProviderPlugin {
    @Autowired @Qualifier("resourceManager") ResourceManager resourceManager;

Loading your plugins is as easy as:

    PluginLoader pluginLoader = new PluginLoader(MyPlugin.class);
    Collection<MyProviderPlugin> providers = 

An example usage of the plugin loader would be to inject plugins into your application context somwhere along these lines:

public class MyAppConfiguration {
    public ProviderRepository providerRepository() {
        PluginLoader pluginLoader = new PluginLoader(MyPlugin.class);
        // Inject another bean reference into the plugin context
        pluginLoader.provideBean("resourceManager", resourceManager());
        Collection<MyProviderPlugin> providers = 
        return new ProviderRepository(providers);
Posted in Java, Spring | Leave a comment