Back in April, VMware introduced Cloud Foundry to the world and with it came super-simple application deployment for Grails developers. Fast forward several months and now another piece of the jigsaw is in place: Micro Cloud Foundry. You can now have your own Cloud Foundry instance for testing or any other use case. And of course, it's incredibly easy to use from Grails.

So what is Micro Cloud Foundry? The following screencast gives you a brief overview of the product and then takes you through the process of downloading, installing and configuring it. At the end, you get to see how you can…

One of the many nice features of Grails is the way it will automatically create your database schema for you from your domain model. Admittedly it's a feature of Hibernate that Grails uses, but still, it helps you get started very quickly with database-driven web applications without having to worry about the database schema.

What happens once your application moves to production? During development, losing the data in between server runs isn't a big issue. But you can't just drop the database in production. So that rules out the "create" and "create-drop" values for the dbCreate data source…

Last week the availability of RabbitMQ as a service on Cloud Foundry was announced. Any application running on Cloud Foundry may now send and receive messages via a RabbitMQ broker that can be provisioned as a service with a single command (e.g. 'vmc create-service rabbitmq'). Instances of the messaging service may be shared between applications, and since RabbitMQ is a protocol-based broker, those applications may even be written in different languages. So, this is an exciting announcement for those interested in modular, polyglot, event-driven applications running in the cloud. I will be…

Spring has rich support for transaction management through its PlatformTransactionManager interface and the hierarchy of implementations. Spring's transaction support provides a consistent interface for the transactional semantics of numerous APIs. Broadly, transactions can be split into two categories: local transactions and global transactions. Local transactions are those that affect only one transaction resource. Most often, these resources have their own transactional APIs, even if the notion of a transaction is not explicitly surfaced. Often it's surfaced as the concept of a session, a…

I looked at what a basic FactoryBean is in my previous post. While FactoryBeans are important - and knowing what they do can help you navigate the framework more effectively - they're by and large no longer the recommended approach to the task as of Spring 3.0 and the imminent Spring 3.1.

The whole point of a FactoryBean is to hide the construction of an object - either because it's very complex or because it can't simply be instantiated using the typical constructor-centric approach used by the Spring container (maybe it needs to be looked up? Maybe it needs a static registry method?) Spring has also supported the factory-method attribute in the XML format. The Java configuration approach offers a conceptually similar (in practice, the result is the same) alternative, but features a more concise, type-safe alternative.

Spring 3.0 saw the introduction of Java configuration which lets you define beans using Java. For instance, to register a regular javax.sql.DataSource with Spring in XML, you will more than likely delegate to a properties file for the sensitive configuration information (like a database password) and use Spring to instantiate the javax.sql.DataSource, like this:

<beans ...>
	<context:property-placeholder location = "ds.properties" />

	<bean id = "ds" class = "a.b.c.MySqlDataSource">
	  <property name = "user" value = "${ds.user}"/>
	  <property name = "password" value = "${ds.password}"/>
	</bean>
</beans>

This is a simple bean, and translates naturally into Java configuration. It would look like this:

 
import a.b.c.* ;
	
@Configuration 
@PropertySource("ds.properties") 
public class MyConfiguration { 
    @Inject private Environment env ; 
	
    @Bean public MySqlDataSource ds(){ 
        MySqlDataSource ds = new MySqlDataSource () ; 
        ds.setUser( env.getProperty("ds.user") );
        ds.setPassword( env.getProperty("ds.password…

In this post, I'll look at Spring's org.springframework.beans.factory.FactoryBean<T> interface. The definition of this interface is:

public interface FactoryBean<T> {
  T getObject() throws Exception;
  Class<T> getObjectType();
  boolean isSingleton();
}

A FactoryBean is a pattern to encapsulate interesting object construction logic in a class. It might be used, for example, to encode the construction of a complex object graph in a reusable way. Often this is used to construct complex objects that have many dependencies. It might also be used when the construction logic itself is highly volatile and depends on the configuration. A FactoryBean is also useful to help Spring construct objects that it couldn't easily construct itself. For example, in order to inject a reference to a bean that was obtained from JNDI, the reference must first be obtained. You can use the JndiFactoryBean to obtain this reference in a consistent way. You may inject the result of a FactoryBean's getObject() method into any other property.

Suppose you have a Person class whose definition is thus:

public class Person { 
 private Car car ;
 private void setCar(Car car){ this.car = car;  }	
}

and a FactoryBean whose definition is thus:

public class MyCarFactoryBean implements FactoryBean<Car>{
  private String make; 
  private int year ;

  public void setMake(String m){ this.make =m ; }

  public void setYear(int y){ this.year = y; }

  public Car getObject(){ 
    // wouldn't be a very useful FactoryBean 
    // if we could simply instantiate the object…

Welcome to another edition of "This Week in Spring." August is well underway and soon, at the end of August, VMworld 2011 will be upon us. Shortly thereafter, SpringOne will be here. It's going to get hot and heavy very quickly, so get ready! This week's "This Week in Spring" has a lot of interesting content from Gordon Dickens, of Chariot Solutions. Thanks Gordon for all the good reading!

1. Rod Johnson - Spring's founder and thought leader - did a keynote at TheServerSide earlier this year. This post relays some of the content of that keynote, including his thoughts on cloud computing, SOA, and more. Check it out.

<LI> 
	The video of the recent webinar, "<A href="http://www.springsource.org/node/3194">What's New in Apache Tomcat 7</a>," is now available on the <a href="http://www.youtube.com/SpringSourceDev">SpringSourceDev YouTube channel</a>.   
</LI> 
<LI>Luke Taylor has some great content on how to <a href="http://blog.springsource.com/2011/08/01/spring-security-configuration-with-scala/">configure Spring Security with the Scala DSL</a> he's been developing. Check it out! 
</LI> 
<LI> 
	<a href= "http://www.springsource.org/node/3192">Spring Data JDBC Extensions with Oracle Database Support</a>…

Not too long ago, I introduced DSL descriptors (DSLDs) for Groovy-Eclipse. DSLDs are Groovy scripts that provide rich editing support (content assist, navigation, etc.) for Groovy projects in your Eclipse workspace. Since DSLDs can only be executed inside a running Eclipse process, debugging is not as simple as firing up the Eclipse debugger and stepping through a Groovy script. In this post, I'll describe some simple and some more complex techniques that you can use for debugging your DSLDs.

To get all of this working, you will need the latest development builds:

• Groovy-Eclipse: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.7/
• STS Grails Tooling (optional, for debug evaluations): http://dist.springsource.com/snapshot/TOOLS/nightly/e3.7
• AJDT (optional, for debug evaluations): http://download.eclipse.org/tools/ajdt/37/update

Simple and crude

The simplest and crudest way to debug your DSLDs is by using println. This will print expressions to the standard out of the running Eclipse process, which can be seen if you launched your Eclipse from the command line. However, I recommend using a log statement instead. This will print logging information to the Groovy event console…

In a previous article, Behind the Spring Security Namespace, I talked about how the Spring Security namespace has been very successful in providing a simple alternative to plain Spring bean configuration, but how there is still a steep learning curve when you want to start customizing its behaviour. Behind the XML elements and attributes, various filters and helper strategies are created and wired together, but, short of reading the code which handles the XML parsing, there is no easy way of working out which classes are involved or the details of how they interact.

For some time now, we've been trying to come up with an alternative Java-based solution using Spring's @Configuration classes that retains the simplicity of the XML namespace but also makes the underlying behavior more transparent and easier to customize. While theoretically possible, no Java-based solution seemed to meet…