Google AppEngine, Vaadin, Spring, a Match Not Made in Heaven

Over the last month, I’ve been learning more and more about Vaadin. I’ve also become more and more convinced that this could be the future of rich Internet application development for Java. Vaadin is an incredible powerful framework that solves many of the front-end difficulties developers have to deal with.

In this regard, Vaadin is the missing link for Java web application development. My current favorite technologies are:

  • Google App Engine for hosting. Although calling Google App Engine (GAE) a Java host might be doing it a little disrespect. But until I’ve really had time to really dive into GAE, that’s exactly what it is for me: a cheap, reliable and scalable place to put Java web applications (with some limitations).
  • The Spring framework is what ties together pretty much every enterprise application. Its dependency injection container and the incredible number of integrated technologies make this the one stop shop for Java developers: MVC, webflow, JPA, transaction management, JavaScript, security, etc. The introduction of many new features in a rather short timespan, might be turning Spring into a beast with many heads instead of the lean mean framework it used to be. For now, there is no alternative.
  • Vaadin, obviously.

And that’s all you need. It seems easy, only 3 technologies and no more. The reality is a little different.

I started both my GAE and Vaadin test projects in Eclipse. Although I don’t really have a preference when it comes to IDEs, it was the obvious choice because both GAE and Vaadin have Eclipse plugins that make development a lot easier. It took a little experimenting, but in the end, both worked together and I was a happy developer.

Until I wanted to add Spring to the mix. Spring, by its nature, comes with tons and tons of dependencies to many Java projects. And while this is the strength of Spring, it also showed the limitations of the dependency management in Eclipse (or actually the lack thereof).

For better or for worse, when it comes to dependency management, Java applications have only one popular tool and it’s called Maven. This is where things went wrong. I created a Maven project, I even used the GAE archetype that comes with this maven plugin. I tried the M2Eclipse integration, which is great BTW. But nothing seemed to correctly configure the Google AppEngine plugin. It never found the appengine-web.xml configuration file.

It took me a while, but eventually I figured out, the GAE plugin does not support the traditional Maven project structure. A real shame in my humble opinion.

Luckily I found the solution: Just before publishing I found this blogpost. Patrik has created an archetype that creates the files in just the right location. You still need to be able to stomach the pretty inconsistent project structure, but at least everything works.

The Vaadin wiki also has a lot of useful information.

Update: If you want the full solution to this problem, please check this follow up post.

(image credit)

  • It would be great to hear the end of the story – to see the resulting application. If you would publish a project skeleton (maybe as Maven archetype) that integrates all the technologies, it would give a good starting point for the others who want to use Vaadin + GAE + Spring together.

  • As far as I know, you only have to change your webapp location to {projectDir}/war, and that's it. With gradle it was a one-liner (webappDirName=/war) and that's it.

    Gradle has its own set of bugs that you would have to deal with, but those are GAE-unrelated 🙂

  • This seems like a great idea. I'll try to set this up next weekend. It would be nice if I can get the Spring example on the Vaadin wiki to work on Google AppEngine. And if all of this still behaves nicely in Eclipse that would be perfect. I'll let you know how it goes.

  • Well, yes and no. Changing the location fixes the plugins problem, but it doesn't configure the plugin. I know this might be asking a little too much, but it's very practical to have all of this information in one file (the maven pom.xml). That file quickly becomes pretty difficult to comprehend, so there's also a disadvantage there. Certainly when you're just a small team, you might just as well check in the Eclipse project files (I've been tempted)
    BTW I really need to try out Gradle one of these days. It seems to be a much more concise way of specifying a project and its dependencies.

  • Pingback: Maven, Spring, Vaadin and Google AppEngine, Happy Together – Streamhead()

  • Ian

    Truthfully, I just don't know where this love affair with Spring comes from (or Maven). It includes so many libraries I don't know how it could ever have been called 'lite'. Seriously what is this website going to do that you need to put so much crap into it? Use GWT, use the Google appengine ORM. There is nothing you can't do with that combination. You could build a GMail clone with that if you wanted.

  • Thanks. It was easy to understand this material. I am waiting for new information about this theme.

  • You're correct that no one will ever need all the technology that is integrated into the latest version of Spring. There are a few reasons that make me want to use Spring: because of its architecture, Spring forces you to follow good programming practices. You can still mess up, of course, but it's a bit more difficult.
    Secondly, I really like Spring Security, which I will need for this project. Spring Security has a wide range of options to protect your application without being too intrusive.
    Than there's JPA which may or may not be useful for Google AppEngine (I still need to figure that one out) and the ease of unit testing everything.

  • We've had a different problem with Spring and GAE. Users are seeing 500 errors b/c apparently Spring is taking too long to start up. We're taking steps to try to lighten the startup time, but haven't made much progress.

    Anyone have input?


  • Pingback: Daily for February 18th through February 21st — Vinny Carpenter's blog()

  • You might want to try lazy instantiation (….) This should speed up the startup of the application, but of course, will have impact for the first user.
    Otherwise, the solutions become more tricky. Turning of autowiring might make a difference. Also all AOP stuff will probably take up extra time during init. But all of those require reworking your configuration, so keep this as a last resort.

  • Pingback: Alternatives for Maven, Building With Less Frustration()

  • M. Wiemers

    I'd like to checkout the sources from Assembla (vaadin-spring-gae), but obviously a user/password is required.

  • M. Wiemers

    Thank you Peter for your advice.

    I have signed up for an account, but it seems to be limited for 30 days. I guess after that time it's no longer for free.

  • That is odd, I really thought Assembla has some kind of free option.

    I'm going to dig into this a little further and keep you updated on the situation 🙂

  • Foo

    6 months later your 'next weekend' never happened.
    Put up a project, slacker.

  • Yeah, sorry about that, I should've learned to never publicly announce stuff I might not be able to deliver on.
    But don't worry, I am working on it. I even have proof:
    It's not yet a functional AppEngine project because it's missing a few config files, but they'll be there “pretty soon”. I hope next week, but I'm hesitant to give any precise dates as this is a hobby project (but I'm always open to sponsorship if you want it sooner or want a deadline I will actually keep to)

  • This pretty much sums up what I was going through last night. I’ll test your solution in a second.

    However, being quite new to vaadin, I found that wiring your application w/ Spring IoC is cumbersome when it comes to registering listeners which easily leads to circular reference issues.

  • I’m not using a very deep Spring/Vaadin integration. I don’t configure the dependencies between the graphical Vaadin interface via Spring (I tried that, but it was just overhead). I only inject repositories and a few services into those GUI classes. Those repositories and services, I do configure with Spring.

    Currently I’m using annotation driven configuration. But I have a feeling this has a tremendously negative impact on performance (I have a 20 second loading request). I will be experimenting with this in the future as I don’t think the current performance is acceptable. I don’t know when I’ll get around to this, but I’ll share the results on this blog.

  • Pingback: Vuosi lähestyy loppuaan – Scalaa ja App Engineä ;) | Spagettikoodi()

  • Joe Schmoe

    By “next weekend”, did you mean next weekend of the following year?

  • Well Joe, maybe you should’ve read the entire post.
    There’s a link at the bottom:
    And even that tutorial was improved upon a while ago by this post:
    So yeah, I’ve been working weekends to keep you happy. All for free.