Easy Grails Hosting: Cloud Foundry


These are some (old) notes on my experience with looking for an easy Grails hosting solution. This is a continuation of this post where I explored Heroku for Grails hosting.


Wikipedia defines Cloud Foundry as

“Cloud Foundry is an open source cloud computing platform as a service (PaaS) software developed by VMware released under the terms of the Apache License 2.0. It is primarily written in Ruby. The source and development community for this software is available at cloudfoundry.org”

Cloud Foundry is also a hosted service provided by VMWare, the principal company behind the Cloud Foundry platform. In addition to VMWare, several companies provide hosting services.

How does Cloud Foundry stack up against my original requirements?

  • Free or cheap to get started

    • appfog offers unlimited apps with 2 GB RAM and 100 MB storage, using their sub-domain
    • Cloudfoundry.com is currently free. Actually, they’re in a sort of beta mode, and there is no information on a non-free account. Currently the limits are 2 GB of memory and 2 GB of storage.
  • No vendor lock-in. If I want to move to another provider, no code changes necessary

    The Cloud Foundry platform is open source (Apache License 2.0), and there are multiple providers as I previously noted, so check.

  • Ability to scale up the number of instances and amount of memory easily

    Instances can be scaled up on-demand via their VMC command line utility.

  • Minimal effort to set up a Grails application

    Cloud Foundry has excellent Grails support. Not surprising considering VMWare is behing both Grails and Cloud Foundry. The Cloud Foundry Grails plugin makes it easy to deploy, update, and overall manage your Cloud Foundry-based Grails application. This post is a good getting started guide.

  • Support for MySQL or PostgreSQL, and MongoDB

    All of these are supported by Cloud Foundry as services. The getting started guide lists the available services (see left menu).

  • HTTPS support

    Cloud Foundry supports HTTPS out of the box, but it sounds like that terminates at their load balancer, so communication between the load balancer and your instance is unencrypted. Not a big deal for me, at least when starting out. Other providers like appfog may more fully support SSL.

Another interesting point on Cloud Foundry is that you can run your own instance of Cloud Foundry via Micro Cloud Foundry and VMWare. Looks like it’s also possible to run it on VirtualBox

I deployed my Grails 1.4 based app to cloudfoundry.com, using the MySQL and MongoDB services. It pretty much worked as advertised and was a breeze to get started with. I had to increase my instance’s memory limit from the default 512MB, but that was easy to do via VMC.

I also ran into this problem with Grails and Spring Security on Cloud Foundry. The solution of adding the following to BuildConfig.groovy worked for me.

compile ":webxml:1.4.1"

I was running with Grails 1.4, so the latest Grails 2.* may not have this problem.

Posted in Grails | Tagged | Leave a comment

XText2: Starting a project for a GWT GUI DSL

This is the first in a series of posts where I’ll explore XText2 by porting an existing XText1-based DSL to XText2. The DSL to be ported is a GUI-description language based on the Sculptor DSL that generates Google Web Toolkit UIs using the Activities and Places framework.

The first step is to set up a new XText2 project and prepare it to start adding elements from the existing DSL. We can create the XText 2 project via the steps in the First Five Minutes Tutorial.


Once the project is set up, let’s replace the starter DSL in GuixDsl.xtext with a couple elements of the real DSL; a minimal View and Gui Module definition:

grammar org.guixdsl.Guixdsl with org.eclipse.xtext.common.Terminals

generate guixdsl "http://www.guixdsl.org/Guixdsl"

DslAbstractGuiElement :
    DslGuiModule | DslView;
    'Module' name=ID '{'
        ("hint" "=" hint=STRING)?
    'View' name=ID '{'

The language artifacts, including the Eclipse editor, can be generated by selecting the Guixdsl.xtext file and selecting  context->Run As->Generate XText Artifacts.


The first time you generate language artifacts, the MWE2 workflow prompts you as to whether you want to download the ANTLR 3 parser generator (recommended), which it has to do due to a license conflict of some sort. Say yes and proceed.


Once the language artifacts have been generated, we can take the DSL out for a spin by selecting the org.guixdsl project, and selecting context->Run As->Eclipse Application.  This will launch a new Eclipse instance with our DSL plugins installed.  Once in the new Eclipse instance, we can create a new test Java project, and create a test DSL file in the project source folder.


If you get a dialog that asks whether you want to add the Xtext nature to the test project, be sure to say Yes. I thought this was only needed to edit the language grammar or code generators. I found out the hard way that your custom code generator won’t get executed unless you have the XText nature enabled, but oddly enough, the JVM model inferrer will. But more about the code generator and inferrer below.


We’ll come back to this test project throughout the development of the new DSL to test out different features. For now, we just want to make sure our minimal DSL and generated language artifacts worked ok.

One of the new features of XText2 is the ability to map DSL concepts directly to Java types, which XText then directly generates code for. This mapping is defined by implementing an inferrer class that extends AbstractModelInferrer.

Of course, generating code via templates is still supported, and done by defining a class that implements IGenerator. When you create a new XText project, by default it’s set up to use the generator strategy rather than the inferrer. Our goal is to use both. The existing XText1-based project uses XPand templates, which can be converted to XTend2 templates. At the same time, we’d like to start using the Java types inferrence approach for some classes.

It wasn’t obvious how to switch to using the inferrer strategy. Close inspection of the “Five simple steps to your JVM language” tutorial showed what needed to be changed to start using the inferrer. In your xtext grammar, replace:

grammar org.Guixdsl with org.eclipse.xtext.common.Terminals


grammar org.Guixdsl with org.eclipse.xtext.xbase.Xbase

Run the GenerateGuixdsl.mwe2 MWE2 workflow to generate everything, including the code generation infrastructure, based on the DSL.


This yields a JVM model inferrer class ready to go:

package org.guixdsl.jvmmodel

import com.google.inject.Inject
import org.eclipse.xtext.xbase.jvmmodel.AbstractModelInferrer
import org.eclipse.xtext.xbase.jvmmodel.IJvmDeclaredTypeAcceptor
import org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder
import org.guixdsl.guixdsl.DslModel

 * <p>Infers a JVM model from the source model.</p> 
 * <p>The JVM model should contain all elements that would appear in the Java code 
 * which is generated from the source model. Other models link against the JVM model rather than the source model.</p>     
class GuixdslJvmModelInferrer extends AbstractModelInferrer {

     * convenience API to build and initialize JVM types and their members.
	@Inject extension JvmTypesBuilder

	 * The dispatch method {@code infer} is called for each instance of the
	 * given element's type that is contained in a resource.
	 * @param element
	 *            the model to create one or more
	 *            {@link org.eclipse.xtext.common.types.JvmDeclaredType declared
	 *            types} from.
	 * @param acceptor
	 *            each created

This works great, but switching to use the XBase base grammar caused the generator strategy to get disabled. For this DSL, we need to be able to generate some classes via JVM inference, and some via template-based code generation. Thanks to the this post on RCP Vision for info on this & how to re-enable the generator.

What happened is XText switched the generator from our generator, GuixdslGenerator, to org.eclipse.xtext.xbase.compiler.JvmModelGenerator, which generates code based on inferred types.

You can see the binding in the AbstractGuixdslRuntimeModule generated module in the org.guixdsl project where both the generator and the inferrer are bound.

	// contributed by org.eclipse.xtext.generator.xbase.XbaseGeneratorFragment
	public Class<? extends org.eclipse.xtext.generator.IGenerator> bindIGenerator() {
		return org.eclipse.xtext.xbase.compiler.JvmModelGenerator.class;

	// contributed by org.eclipse.xtext.generator.xbase.XbaseGeneratorFragment
	public Class<? extends org.eclipse.xtext.xbase.jvmmodel.IJvmModelInferrer> bindIJvmModelInferrer() {
		return org.guixdsl.jvmmodel.GuixdslJvmModelInferrer.class;

To re-enable the generator class, update the binding in GuixdslRuntimeModule, which extends AbstractGuixdslRuntimeModule and is generated only once (can be modified whereas AbstractGuixdslRuntimeModule cannot).

     * Avoid using the default org.eclipse.xtext.xbase.compiler.JvmModelGenerator
     * when using xbase.
     * @see org.guixdsl.AbstractGuixdslRuntimeModule#bindIGenerator()
    public Class<? extends IGenerator> bindIGenerator() {
        return GuixdslGenerator.class;

Now the generator is back and getting invoked, but generation isn’t happening for any inferred types. This is because although the inferrer is getting called, the JvmModelGenerator is the class that actually generates the code, and we just switched it off above. We want to have both our custom generator, and generation based on inferred types. To enable both, modify our generator to extend JvmModelGenerator, and delegate to it.

class GuixdslGenerator extends JvmModelGenerator {
	override void doGenerate(Resource resource, IFileSystemAccess fsa) {
		super.doGenerate(resource, fsa)


Now both will work:

  • Generation of any inferred types we define in GuixdslJvmModelInferrer
  • Custom, template-based generators defined in GuixdslGenerator

In a future post, we’ll add support for package definitions to the language, and start generating GWT code.

Posted in Java, MDSD | Tagged , , , , , | Leave a comment

Easy Grails hosting

I started a new Grails-based project, and went out looking for an easy to set up Grails hosting option. I currently have a virtual server hosted with Rackspace (originally Slicehost). For a couple reasons, I want to keep this new application on its own server. I could get an additional virtual server from Rackspace, and start setting up SSH, Apache Web Server, Tomcat, MySQL, MongoDB, and whatever else came up, which I’ve done many times, but the setup and administration takes a significant amount of time, which could instead be spent on developing the app.

My requirements are:

  • Free or cheap to get started
  • No vendor lock-in. If I want to move to another provider, no code changes necessary.
  • Ability to scale up the number of instances and amount of memory easily
  • Minimal effort to set up a Grails application
  • Support for MySQL or PostgreSQL, and MongoDB
  • HTTPS support

Ideally, I’d also like to be able to:

  • Download my server image and run it locally via VirtualBox or similar
  • Run my server image on a different cloud provider

As a reference point on pricing, Rackspace currently offers the following Cloud Server configurations:

  • Instance with 512MB memory, 20GB storage: $16/mo
  • Instance with 1GB memory, 40GB storage: $44/mo

Interestingly, Rackspace is transitioning to an Openstack-based platform.

Looking at the PaaS (platform-as-a-service) providers, I’ve been hearing about Heroku for a while. Heroku looks very easy to get started with, and the add-on services that are available look impressive.

Kudos to the Heroku website, very slick and inviting. On to the substance..

As far as pricing,

  • 1 web dyno, up all the time with a dev database (10K rows) is free
  • 1 web dyno, up all the time with a “crane” production database (400 MB cache, 1TB storage) is $50/mo
  • 2 web dyno, up all the time with a “crane” production database (400 MB cache, 1TB storage) is $85/mo

Basically, each additional web dyno is approximately $35/month, and each doubling of production database cache doubles the price, starting with $50 for the “crane” database.

But what exactly is a web dyno or a “crane” database?

According to the Heroku website, “A web dyno runs your code and responds to HTTP requests. More dynos provide more concurrency” Sounds like a thread, which would be really bad in relation to the pricing.

But drilling into the details, A dyno is defined as “the basic unit of composition on Heroku, is a lightweight container running a single user-specified command. You can think of it as a virtualized unix container”. Which sounds more like a virtual server instance, and is more reasonable.

The standard Heroku database offerings are based on PostgreSQL, with different pricing based on the amount of cache you need, “crane” being the lowest.

What about HTTPS/SSL support? This add-on provides SSL support at $20/month. On further digging, SSL does work out of the box using a shared certificate and a heroku.com-based domain name. The $20/mo add-on lets you use your own certificate for your own domain.

So Heroku looks to be a bit pricier for a small production instance than setting up your own virtual server, but with less setup and administration work, and an easier path to scale up.

But the show-stopper for me was the deployment model. In Heroku, deployment means pushing your source code to Heroku, which they then build and deploy themselves. I’m aware of the argument that if someone has access to your deployable artifacts, and therefore the bytescode, they can decompile source code. But decompiled source code isn’t the same as the original, and it feels wrong to make it so darn easy for someone to steal your intellectual property if there’s a security breach.

In my next post, I’ll explore CloudForge.

4/14/2013 Update:
Heroku added support for WAR deployment via their Heroku Enterprise for Java offering. Looks like pricing information isn’t publicly available though.

Posted in Grails | Tagged , | 4 Comments

Making Eclipse run configurations portable

I’m using Eclipse, GWT, and Maven on a couple projects, and have several customized Eclipse run configurations I use. There’s a bit of work and specific settings required to make these work well, and they have to be set up for each new workspace, so I’d like to set them up once and share them with the team.

Before being able to check these into source control, and make them available to the rest of the team, there’s a couple things in these run configurations that have platform-specific references (e.g. the full path to files on my hard drive) that have to be fixed. Fortunately, if you know where to look it’s not hard to change.

First, the GWT launch configuration which is generated by the Google Eclipse Plugin needs to be fixed. As described in this stackoverflow question, the classpath used by the launcher contains a hard-coded full path to the GWT development jar on your computer. The solution is to change the path to be relative to a classpath variable which is defined at the workspace level. In my case, I need to use the M2_REPO classpath variable which points to my local Maven repository.

To change this, open the Eclipse Run Configuration for the GWT launcher in question, select the Classpath tab, click the “Advanced” button on the right to add a new classpath entry, choose “Classpath Variable” in the dialog that comes up, then choose the classpath variable you want to use. Assuming the jar file you need to select is in a subdirectory below the classpath variable, click on “Extend” to navigate to the jar file relative to the classpath variable.

Once your new classpath entry is in place, you can remove the old one with the hard-coded path.

For the Maven run configurations, the only thing that was platform-specific was the base directory setting on the first tab, which by default is the full directory path to the project.

To make this portable, you can make this location relative to the named project that’s loaded in the current workspace. Click “Browse Workspace…” and select the project that the Maven build should run from. You’ll end up with a location like ${workspace_loc:/my-project}.

For both of these run configurations, the last thing that needs to be done is to save them as a file within the project. Select the last tab of the run configuration, “Common”, select “Shared File” under “Save as”, and choose a directory for the run configuration to be saved to.

. You can now check these files into source control and load them into another workspace.

Posted in Tools | Tagged | 5 Comments

Sculptor lately

The latest version, 2.1.0, of Sculptor came out and it has some great features including JPA 2.0 support, custom finder methods generated from the DSL, and a fluent domain object builders feature I contributed.

Other than the builders feature, I haven’t been able to work with the new features as I’m working on a Sculptor GWT GUI branch based on the 2.0 release. At some point I’ll migrate my branch to the latest and get to use these goodies.

On the horizon, there’s work being done on migrating Sculptor to the latest versions of XText and XTend which look like great advancements, and Hibernate 4.X support has just been added to trunk by Oliver Ringel.

Not tied to a particular release, but Torsten Juergeleit has also done some great work with a new all-in-one Maven Sculptor plugin which does the work of what used to be 3 separate plugins.

Lots of exciting developments for Sculptor. I’ll write more on the Sculptor GWT GUI work in a future post.

Posted in MDSD | Tagged | Leave a comment

Java multiple dispatch / multimethod libraries

Multiple dispatch (aka multimethods) is a method dispatch feature of some languages whereby the method that is dispatched to is based on the runtime type of the method arguments, not just the runtime type of the class being called (single dispatch polymorphism), and compile-time type of the method arguments.

Java doesn’t support multiple dispatch at a language level, but fortunately, it can be implemented in a library.

A simple test program to show Java behavior:

public class Mapper {

	static abstract class Content {}

	static class Link extends Content {}
	static class Message extends Content {}
	void map(Content c) {
		System.out.println("shouldn't get here!");
	void map(Link l) {
		System.out.println("It's a Link");
	void map(Message m) {
		System.out.println("It's a message");
	public static void main(String[] args) {
		Mapper mapper = new Mapper();
		Content c1 = new Link();
		Content c2 = new Message();

The output for the above test program is:

shouldn't get here!
shouldn't get here!

Java is dispatching to the overloaded map method based on the compile-time type of c1 and c2, which is the Content class. The above example is a bit contrived, but it shows that when working with base class references, for instance if you are working with a List of Content objects, Java won’t dispatch based on the runtime type.

I set out looking for a library that would implement multiple dispatch. I was a bit surprised the Google Guava library didn’t implement it. This seems to be right up their alley. What I did find was the following implementation: jmultimethod

Nice and simple, multiple dispatch using annotations and reflection.

Using jmultimethod, our test program becomes:

package org.sculptor.mapprovisions.domain;

import jmultimethod.Multi;
import jmultimethod.Multimethod;

public class Mapper {

	// Object responsible for doing the dispatching
    protected static Multimethod mapMM =
        new Multimethod("map", Mapper.class);

	static abstract class Content {}

	static class Link extends Content {}
	static class Message extends Content {}
	public void map(Content c) {
		System.out.println("shouldn't get here!");
	public void map(Link l) {
		System.out.println("It's a Link");
	public void map(Message m) {
		System.out.println("It's a Message");
	public static void main(String[] args) {
		Mapper mapper = new Mapper();
		Content c1 = new Link();
		Content c2 = new Message();
		// Invoke the multiple-dispatch method "map" on mapper, passing c1 as an argument
		mapMM.invoke(mapper, c1);
		// Invoke the multiple-dispatch method "map" on mapper, passing c2 as an argument
		mapMM.invoke(mapper, c2);

The new output is:

It's a Link
It's a Message

I’d still prefer to have it directly supported by Java, but it’s good to have this solution when needed.

Posted in Java | Leave a comment

Web and mobile UI wireframes

People think visually. A picture is worth a thousand words as the saying goes.

We’ve recently been using Balsamiq to put together wireframes we use to work out user experience concepts, and to work with stakeholders. Balsamiq is an Adobe AIR-based desktop application that can be used to quickly put together web and mobile UI wireframes. It’s also relatively easy to make clickable demos in Balsamiq by stringing together screen wireframes.

What I probably like most about Balsamiq, is the wireframes have a rough and unfinished look to them. They get the point across, but purposefully look informal so people focus on the general concepts and information presented on the UI, and not the color or exact positioning of buttons.

If you’re an OmniGraffle user, there’s some stencils that are also a good option, among them Konigi, and Yahoo Design Stencils (also available for Visio and in other formats).

Posted in General | Leave a comment

Customizing Sculptor to generate Groovy classes

I’ve been using the Sculptor DSL/tool to build Java EE applications based on DDD and EDA principles. This has worked out great, and Sculptor allows me to express the intent at a higher level and more succinctly than I could with straight Java or another GPL.

When it comes to expressing the behavior of your domain, that’s done outside of the Sculptor DSL, using Java. The Sculptor DSL is largely about the solution structure; the structure and relationship between classes, and what standard behaviors they support, such as CRUD repository methods. If you need to implement complex logic for your credit score calculator class, Sculptor is used to define the interface into your method, but it’s up to you to implement the logic for that method in Java. After a while, I found this was significantly slowing me down. Java is so verbose compared to languages such as Groovy or Scala, in particular when it comes to working with object graphs and functional programming.

Fortunately, Sculptor and the XText tools it is based on support customizing each step of the generation process. This post outlines what I did to customize Sculptor to allow me to implement my domain and service classes in Groovy. This only applies to the concrete implementation classes you would customize when using the ‘gap’ generation option. The base classes that are regenerated each time are still Java, as there was no benefit to using a different language for them.

The following changes should be made to the business tier project.

Maven POM updates

First, the Groovy libraries and a Groovy compiler need to be added to the Maven build Traditionally this was done using the GMaven plugin, but I came across this post that describes using the eclipse-groovy plugin to jointly compile Java and Groovy together in a single pass. Much better.

To use this, modify the pom.xml to add the springsource maven dependency and plugin repositories:



Then update the maven-compiler plugin in the build/plugins section to use the groovy-ecilpse-compiler:


Finally, add groovy to your dependencies:


Xpand templates

The next step is to create Xpand templates that will generate Groovy class files instead of Java. I’m using the Sculptor ‘hint’ feature to control whether a class will get generated as Java or Groovy. If a Service or Domain class is annotated with hint=”gapImpl=groovy”, Groovy will be generated, otherwise it’ll fall back to the default of Java.

The code below defines an aspect for the generation of the DomainObject and Service sub-classes. Whenever these templates are invoked within Sculptor, the aspect below will be evaluated, deciding whether to generate Groovy code or to proceed with the normal Sculptor templates.

Add to src/main/resources/templates/SpecialCases.xpt:

«AROUND *::domainObjectSubclass FOR DomainObject»
        «IF getHint("gapImpl") == "groovy"»
                «EXPAND Groovy::Groovy»         

«AROUND *::serviceImplSubclass FOR Service»
        «IF getHint("gapImpl") == "groovy"»
                «EXPAND Groovy::GroovyService»      

Next, define the templates that will generate the actual Groovy code. Since Groovy syntax is practically a superset of Java, I was able to copy the code from the existing Sculptor templates (DomainObject.xpt and Service.xpt). The one key difference is where the code gets generated to – a new helper function groovyFileName returns a .groovy file name.

Create src/main/resources/templates/Groovy.xpt:

Templates to generate Sculptor implementation classes as Groovy

«IMPORT sculptormetamodel»
«EXTENSION extensions::helper»
«EXTENSION extensions::groovyhelper»
«EXTENSION extensions::properties»

«DEFINE Groovy FOR DomainObject»
«FILE groovyFileName(getDomainPackage() + "." + name) TO_SRC»
package «getDomainPackage()»;

«IF formatJavaDoc() == "" -»
 * Data transfer object for «name». Properties and associations are
 * implemented in the generated base class {@link «getDomainPackage()».«name»Base}.
«ELSE -»
«EXPAND templates::DomainObject::domainObjectSubclassAnnotations»
public «getAbstractLitteral()»class «name» extends «name»Base {
        «EXPAND templates::DomainObject::serialVersionUID»
    «IF getLimitedConstructorParameters().isEmpty || getMinimumConstructorParameters().isEmpty»public«ELSE»protected«ENDIF» «name»() {

    «EXPAND templates::DomainObject::propertyConstructorSubclass»
    «EXPAND templates::DomainObject::limitedConstructor»
    «EXPAND templates::DomainObject::minimumConstructor»


«DEFINE GroovyService FOR Service»
	«FILE groovyFileName(getServiceimplPackage() + "." + name + "Impl") TO_SRC»
package «getServiceimplPackage()»;

 * Implementation of «name».
«IF isSpringAnnotationToBeGenerated()»
«IF webService»
«EXPAND webServiceAnnotations»
public class «name»Impl extends «name»ImplBase {

    public «name»Impl() {
	«EXPAND templates::Service::otherDependencies»

    «EXPAND templates::Service::implMethod FOREACH operations.select(op | op.delegate == null && op.serviceDelegate == null)
    	.reject(e|e.hasHint("EventSourcingScaffold")) »

Xtend helper function

The last step is to define the helper function used above to return the groovy file name.

Create src/main/resources/extensions/groovyhelper.ext:

import sculptormetamodel;

String groovyFileName(String name) :
    name.replaceAll("\\.", "/") + ".groovy";

Model file

Finally, to use this, add the hint to whatever Service or Domain classes you need it for in your model file:

		Service MyService {
Posted in MDSD | Tagged , | Leave a comment

Fornax Sculptor DSL tool: Switching an existing app to MongoDB

Fornax Sculptor is a DSL, Eclipse-based editor, and set of code generators used to build Java/JEE applications.  You define your model and other parts of your application in the Sculptor textual DSL, and the Sculptor model transformations and code generators generate Java code, Spring configuration, Hibernate mappings, and UI code.  Of course, Sculptor only takes you so far, which is where you supply your own code via extension points and composition/delegation, but Sculptor goes a long way to minimize repetitive code, and keeping you working closer to the actual problem domain.  You can also customize and extend Sculptor via the excellent Eclipse MDSD tools (Xtext, MWE, Xpand, Xtend, Check) that Sculptor is based on.

I’ve been building a JEE application using Sculptor, based on JSF2, Hibernate, MySQL, and Spring.  The latest release of Sculptor added support for MongoDB and Events.  I’ve been looking to eventually migrate this application to a distributed & schema-less database, and more of an Event-Driven architecture, so I decided to try converting it.  All in all it went very smoothly.  Following are my notes on switching over a Sculptor application from Hibernate to MongoDB.

Updating the Maven POM and Sculptor configuration

First, remove mysql, hibernate, spring-jdbc and related dependencies from the business tier project pom, then add the following dependency:


Then modify sculptor-generator.properties to switch the persistence tier from Hibernate to MongoDB.  Comment out:


and add:


Run a build:

mvn clean install

Fix domain concrete classes

If you have domain classes with gap classes, as I had, you’ll have some compile errors due to JPA-isms that are in the domain concrete classes. Since these concrete domain classes are generated only once, they don’t get overwritten on the next build and still have the JPA-specific code in them. Edit each concrete domain class that has a gap class, and remove the JPA-isms:

import javax.persistence.Entity;
import javax.persistence.Table;

@Table(name = "LINK")
public class Link extends LinkBase {

The domain base classes don’t have to be modified, because they’re regenerated each build.

Fix references to entity unique IDs in your custom code

Another difference with the MongoDB persistence layer is that the entity unique IDs are Strings rather than Longs. Any place in your hand-written code that uses entity IDs, you’ll need to make this change.

Fix service and repository unit tests

When using the JPA-based persistence tier, the service tests  are based on dbunit, which won’t work with MongoDB.  I did a quick search and didn’t find a dbunit-equivalent for MongoDB.  The Sculptor MongoDB test samples use a technique of setting up test data using Java code and the repository classes:

package my.application.serviceapi;


 * Spring based test with MongoDB.
@ContextConfiguration(locations =  {
public class LinkServiceTest
    extends AbstractDependencyInjectionSpringContextTests
    implements LinkServiceTestBase {
    private DbManager dbManager;
    private LinkService linkService;

    public void initTestData() {
        // Set up your test fixtures here:
        Link link1 = new Link("http://some.com", "Some title");

    public void initDbManagerThreadInstance() throws Exception {
        // to be able to do lazy loading of associations inside test class

    public void dropDatabase() {
        Set<String> names = dbManager.getDB().getCollectionNames();
        for (String each : names) {
            if (!each.startsWith("system")) {

        // dbManager.getDB().dropDatabase();

    private int countRowsInDBCollection(String name) {
        return (int) dbManager.getDBCollection(name).getCount();

    public void testFindById() throws Exception {
        // Your test code and assertions here...


Simply set up your test fixtures using your service/repository classes or the MongoDB DbManager within the initTestData() method.

No support for findByQuery repository method

When building, I got errors such as:

.../LinkAccessFactoryImpl.java:[21,66] cannot find symbol
symbol  : class MongoDbFindByQueryAccessImpl
location: package org.fornax.cartridges.sculptor.framework.accessimpl.mongodb

This is odd since LinkAccessFactoryImpl is a generated class. The cause of this error was that I have findByQuery as one of my scaffolding operations that is generated for every repository. But this type of method isn’t supported by the MongoDb cartridge. In the future it’d be nice if there was a model validation that checked for this and generated an error before generating code. To fix this, remove findByQuery from the list of default scaffolding operations in scupltor-generator.properties, if you have it there at all:


Fix bidirectional associations between aggregate roots

I had a bidirectional association between domain aggregate roots that caused problems. I had something along the lines of:

    Entity A { 
    - Set<@A> children <-> parent 
    - @A parent nullable <-> children 

This resulted in an endless loop in the generated data access code, because it was following both the parent and children associations when mapping the objects to a MongoDB document.

In hindsight, I think this should not be supported within Sculptor when using the MongoDB cartridge. It may make sense for relational databases, but since MongoDB doesn’t support transactions across collections (ditto for most other NoSQL databases), it cannot be guaranteed that both sides of the association will be updated as a unit of work. This also makes distributing your database across many nodes much more complicated. I changed my model to make this a unidirectional association, problem solved.

An interesting point is that with MongoDB and similar databases, the association reference is stored on the “one” side of the association, rather than the “many” side as with relational databases. The document at the “one” side of the association contains a list of IDs of the “many” instances.

Tip: To see how Sculptor maps entities to MongoDB documents, see the “mapper” package within your app.

Add DbManagerFilter to web.xml

Lastly, I had to add the DbManagerFilter servlet filter to the web.xml file. This filter registers a DbManager instance in a thread local so that it may be used to lazy-load associations as needed within your JSF managed bean/Facelets code.


Overall the switch to MongoDB went very smoothly, and there were very few changes I had to make, largely thanks to Sculptor. The most significant change was switching the unit tests from using dbunit to using Java test fixtures.

Posted in MDSD | Leave a comment

ActiveJDBC: an implementation of the Active Record pattern for Java

Igor Polevoy, who I’ve had the pleasure of working with on a couple projects, has just posted his ActiveJDBC project to Google code.  If you work on Java applications that access relational databases, you owe it to yourself to check it out.

ActiveJDBC implements the Active Record pattern, initially documented by Martin Fowler in his book Patterns of Enterprise Application Architecture and popularized by Ruby on Rails.

What’s interesting about ActiveJDBC is how little baggage it brings with it, and how quickly one can get started using it.  It’s pure Java, requires few other libraries (no Hibernate, JPA, etc), and requires no configuration (no mapping, etc).  All metadata is inferred from the database schema.

Some examples of ActiveJDBC in action:

Persistent Book class definition:

import activejdbc.Model;

public class Book extends Model {}

Adding a new Book:

Book b = new Book();
b.set("isbn", "0321127420")
  .set("title", "Patterns of Enterprise Application Architecture")
  .set("author", "Martin Fowler")
  .set("publisher", "Addison-Wesley Professional");

Paging through Addison-Wesley books in sorted order

List<Book> books = Book.where("publisher = ?", ""Addison-Wesley Professional");
  .orderBy("author asc");

It looks like this framework strikes a good balance between a simple framework that works as you expect, and providing an elegant DSL for database access.  This is particularly impressive given Java as a language doesn’t lend itself to implementing DSLs.

One thing I was curious about but didn’t see an example of, was working with associations, which is listed on the features page.

For more info, see the Getting Started Guide on Google Code, Igor’s blog, and the Productive Edge Java blog.

Posted in Java | 1 Comment