One of the most interesting capabilities of Spring Cloud is its extensibility. You can extend it to support additional clouds, enhance already supported clouds, support new services, new service connectors--all without modifying the Spring Cloud code itself. In this blog, we explore this capability. If you haven’t done so already, please read the first and second blog in this series to acquire sufficient background.

The three axes of extensibility

Spring Cloud provides extensibility along three orthogonal directions. You may extend it in one of these directions and orthogonality ensures that…

In the last blog, I showed you how to use Spring Cloud's Java configuration option to obtain service connectors declaratively (there is also XML namespace support, if you need it). In this blog, we will take a closer look at how you would use Spring Cloud programmatically. This will help in the situations where you cannot use Java or XML configuration. It will also demystify how Spring Cloud works and prepare for the next blog in this series, where we discuss extending Spring Cloud.

To work with Spring Cloud we need to access an object of the Cloud class. However, you can’t create a Cloud object directly (its constructor is not public). Instead, you will obtain it through CloudFactory…

Developing, deploying, and operating cloud applications should be as easy as (if not easier than) local applications. That is and should be a governing principle behind any cloud platform, library, or tool. Spring Cloud--an open-source library--makes it easy to develop JVM applications for the cloud. With it, applications can connect to services and discover information about the cloud environment easily in multiple clouds such as Cloud Foundry and Heroku. Further, you can extend it to other cloud platforms and new services.

In this blog (first in a series), I will introduce Spring Cloud and show its usage from the application developer point of view. We will develop a simple application and deploy to Cloud Foundry and Heroku…

If you watched the video for the Cloud Foundry launch event, you saw that we deployed the Spring Travel application downloaded from Spring Web Flow samples, bound a MySQL service to it, and dragged and dropped the application to the Cloud Foundry server in STS, without making a single line of change in the application itself. How’s that possible since the application is configured to use a local database? That’s when auto-reconfiguration comes into play.

Cloud Foundry strives to keep your initial investment low. Beyond dollars and cents, a real investment comes from the time that a developer…

Services offered in Cloud Foundry make writing efficient and effective applications possible. Developers can now choose just the right kind of services without worrying about operating those services. For example, a portion of an application can choose Postgres for the parts where transactional access is crucial, MongoDB where interacting with data as a collection of documents makes sense, Redis where key-value is the right abstraction, and RabbitMQ where messaging helps create effective architecture. In this four-part blog series, we will explore how Spring applications can use Cloud Foundry…

Spring's dependency injection (DI) mechanism allows configuring beans defined in application context. What if you want to extend the same idea to non-beans? Spring's support for domain object DI utilizes AspectJ weaving to extend DI to any object, even if it is created by, say, a web or an ORM framework. This enables creating domain behavior rich objects, since domain objects can now collaborate with the injected objects. In this blog, I discuss the latest improvements in the Spring framework in this area.

The core idea behind domain object DI is quite simple: An AspectJ-woven aspect selects join points corresponding to creation or deserialization of any object matching certain specification. Advice to those join points inject dependencies into the object being created or deserialized. Of course, the devil is in the details. For example, how do you select join point corresponding to deserialization or how do you inject dependency only once per object? By offering a few pre-written…

Spring 2.5 features a new pointcut designator -- bean() that allows selecting join points in beans with a matching name pattern. Now it is possible to use the auto-proxy mechanism along with Spring-AspectJ integration to select a specific bean even when there are more than one beans of a type. Earlier, you could use BeanNameAutoProxyCreator to achieve a similar result; however, that mechanism didn't work with Schema-style or @AspectJ aspects.

Besides selecting a specific bean, this pointcut designator offers two interesting ways to select beans if you follow an appropriate naming convention:

1. Selecting a vertical slice of beans: If you follow a convention where bean names include a string indicating their role from the business perspective, a bean() pointcut can select beans based on their business role. For example, you may use the bean(account*) pointcut to select all accounting-related beans such as accountRepository, accountService, and accountController if bean names start with a string representing their business functionality.
2. Selecting a horizontal slice of beans: If you follow a convention where bean names include a string indicating their role from the architectural perspective, a bean() pointcut can select beans based on their architectural role. For example, you can use bean(*Repository) to select all repository beans if bean names end with a string representing their architectural role. Without the bean() pointcut, you had to rely on the package structure or type-based pointcuts, which can be sometimes a bit too restrictive.

Figure 1: Selecting horizontal and vertical slices of beans based on their names using bean() pointcuts