Back | Next
June 27, 2014

Tech Tip: Geting Started with Spring Boot

Spring Boot is a convention-over-configuration centric approach to application development with Spring.

There are a few ways to get started.

In principal, the easiest way to get started is to just reuse somebody else's handcrafted build file and project setup. There are code-generators that make this easy. The Node-ecosystem tool yo offers a code-generator called generator-jhipster. The projects generated with JHipster are web applications built using Maven, Spring, and Angular.js. The Groovy-language ecosystem codegenerator Lazy Bones can code-generate Spring Boot applications for you, as well.

For me, nothing beats the Spring Initializr. It's simply a small form that's pre-filled out with useful values. You might make sure to specify Java 1.8, and check the boxes for Web, JPA (or any of the other supported data-access technologies like MongoDB), and Actuator. This is a safe first-application. Once you've specified your Java revision (you are on Java 1.8, aren't you?), specify the type of project you'd like. Many people will know what to do with the default, a Maven Project. This will be importable into any IDE, straight-Eclipse, IntelliJ (Community or Ultimate), NetBeans, etc. I'd leave the version ( - the latest stable release) and the project type set to the defaults. Click Generate to download a an archive. Unzip it and then import it into your favorite IDE as a Maven project.

If you're using our open-source Eclipse distribution Spring Tool Suite (STS), there are many ways to get started. We base STS on the latest-and-greatest cut of the Eclipse Java EE distribution, so it represents a stable, well-integrated distibution of Eclipse. The Spring Tool Suite provides extra tools and niceties. One such nicety is a dialog within the IDE that acts as a front for the Spring Initializr. It's nice skipping the download, unzip, and import steps!

The spring.io guides provide easy-to-digest introductions to using Spring (or Spring ecosystem technologies). Each guide is backed by a Github repository that demonstrates the finished project as well as provides a base template that you can fill out when completing the guide. There's a nice feature in STS that lets you import a Getting Started guide directly from the IDE, by going to File -> New -> Import Spring Getting Started Content. This saves you the git clone, and IDE-import.

I've put together a video that shows what it looks like to use the tools in Spring Tool Suite (STS),

June 6, 2014

Spring Integration Adapters, Gateways, and Channels

A community member was a little unclear on the role of Spring Integration adapters, gateways, and channels. I put together a response and thought I'd share it here, too. Here's my response:

A channel is a named conduit between components in a system. By default, it's more or less synonymous with a java.util.Queue. Data goes in one side of the tunnel, comes out the other.

Let's ignore the discussion of channels for a moment.

A gateway is a terminating component, like an inbound/outbound adapter. That is, messages either come in from the outside world (beyond the memory space of your Spring Integration flow) or they leave the Spring Integration flow for some external system or component (also beyond the memory space of your Spring Integration flow).

An adapter receives messages from an external messaging system (JMS, e-mail, SFTP, whatever) and "adapts" it to the messaging system (as a Spring Integration Message<T>). The inbound email adapter takes messages sitting in a mail-box (IMAP, or whatever) and "adapts" it to the Spring Integration Message<T> type. And vice-versa: it takes a Spring Integration Message<T> and "adapts" it to the formats required of an external system. For example, the outbound e-mail adapter takes Spring Integration Message<T>s and turns them into emails that get sent.

Once a message comes in, via an inbound adapter, it flows from one component to another via channels. Ultimately, it might be appropriate to write that message out somewhere. You can write the message using an outbound adapter.

A gateway is just like an adapter, except that it can take replies. So, for example, perhaps a message comes in via JMS, and it has specified a JMS destination to which replies should be sent. The example above can be thought of as an inbound gateway. If you send a message TO a gateway and want the reply to come back via that gateway, then that's an outbound gateway. (Perhaps you've made an HTTP request on one channel through the gateway, and the HTTP response comes back into the system via the gateway on another channel).

The gateway can handle that sort of inbound AND outbound work for the same message flow.

  • Adapters write out, or read in, but not both.
  • Gateways write out and wait for reply, or read in and send response. Gateways only make sense where there's the need for a reply.

Returning now to channels, you don't need to worry about channels most of the time. I worry about them when: I want to make parts of the flow have different concurrency characteristics, when I want to make sure that the transit of messages in the system itself is durable (for example, by switching out the java.util.Queue-ish default channel for something that delegates to JMS for persistence), or when I want to insert auditing logic in a central place (around the channel through which messages flow is a great place for that sort of thing). Often, if you don't mind the default, synchronous java.util.Queue-like behavior, u don't even need to define a channel. Just specify a name where a channel reference is expected. As long as the names are the same, Spring Integration will create the beans for you at runtime and connect wire everything up for you.

In related news: check out this amazing video by Spring Integration lead Gary Russell on using the Spring Integration Java configuration API and DSL.

June 3, 2014

Don't Want to use Maven with Spring?

A reader recently protested that he felt he had to use Maven. I put together a reply that I've extracted here for this blog post.

You're most certainly not required to use Maven. We use Maven-managed dependencies pretty heavily, but, you can use those dependencies via Ant + Ivy, Maven, Gradle, SBT, Buildr (anybody remember that one?), etc. Maven just happens to be what most of the developer community is using, for better or for worse. I (personally) prefer Gradle, but I try to build examples that will work w/ the majority of readers.

I'm sorry we didn't get your favorite build tool. This was simply to show how to get started w/ a fairly common tool. Almost 4 years ago. We have far more up-to-date guides on, for example, Maven and Gradle.

If you want direct downloads, please check out our Artifactory server, and have a look at the Spring Repository FAQ

If you want a VERY quick starter for Spring MVC (and everything else, via Spring Boot), goto the Spring Initialzr, choose the "Web" checkbox, then choose "Generate." It'll download a .zip with both a Maven pom.xml or a Gradle build.gradle. Delete the one you don't want. You'll have a single Application.java. From there, just start coding! Eclipse, IntelliJ, and NetBeans all have great support for Maven. Our free, open-source Eclipse distribution, Spring Tool Suite (STS), has nice support for Gradle.

There's a 10-minute video here on using Spring Boot and STS to build a REST service. This also includes a look at some of the tools STS provides to manage Maven for you. You should just be able to write code and have it bring the correct libraries in for you, automatically.

The nice thing about working with Spring Boot "starter" dependencies (like org.springframework.boot:spring-boot-starter-web:1.0.3.RELEASE) is that they represent everything you're likely to need to build a certain style of application. In this case, that one dependency brings in all the important bits from Spring MVC, JSON support, file upload support, embedded Tomcat, and a lot more. Just add that dependency and add a simple REST controller and you can run it, as shown in that aforementioned video. This approach should hopefully represent a much simpler workflow for using Maven or Gradle.

April 19, 2014

Devoxx France 2014

This last week I've been in Paris, France talking to developers about Spring 4 and Spring Boot. I landed on Sunday, gave myself a day to recover from any jet lag. The jetlag sorted itself off within a few days but left me very, very tired the day of a my webinar for the SpringSourceDev YouTube channel. When we on the Spring team give webinars, we do two of them - one for those in Europe and the middle-east and another for north America. The hope is that this presents an opportunity for developers around the world to join the fun. So, as usual, I tested the hotel Wi-Fi's strength by conducting a Skype video call and a Google+ hangout. Worked fine. 16:00 CEST rolls around and I connect to do the first webinar, say a few words and then - (gasp!) - silence! I was disconnected! I called downstairs and asked what happened: they were changing ISPs! You could've knocked me down with a feather. I was about to address a lot of people and here the hotel's decided to switch ISPs! I ran down the hallway, descended and implored whoever could help to please help me. The lobby had a separate network, so I connected and presented my first webinar in the middle of a Marriot lobby as people walked by, talking, laughing, screaming. Amazing. Quel cauchmar!

The second webinar went off with far less fanfare, happily.

This year's Devoxx was amazing! I came bearing messages of Spring 4 and Spring Boot. The talks seemed to draw a large crowd and it was clear that people are very interested in both, especially in so far as you can use the Spring 4 technologies inside of Spring Boot.

I'm looking forward to being at Devoxx UK in a months time and, hopefully, Devoxx Belgium later this year.

Now, I'm on a plane headed to Bangalore, India for the Great Indian Developer Summit where I'll also be presenting on Spring Boot and Spring 4, among other things. Every trip to India I've ever taken has been amazing, and I don't expect this one will be any different! C'ya there!

I'd like to think these people were reacting to me, but my hunch is that they're just happy because of Spring and Spring Boot. :D







January 1, 2014

It's 2014: Happy New Year!

Just wanted to wish everyone a happy and healthy new year. I hope you spent it with family and friends, and maybe a good piece of code on your mind. :-)

The year's already off to a great start for me. For others, not so much. It seems that @Skype's Twitter account's been hacked. Was sort of strange to see this series of Tweets this morning:

November 12, 2013

Spring Boot M6's new Security features

Spring Boot is a super impressive way to get started. Check out the various Getting Started guides for more on Spring Boot itself. Spring Boot exposes great metadata about the application from HTTP when you depend on the spring-boot-starter-actuator. Now, with M6, you can access that same information (and more!) from SSH! Here's a screencast I created demonstrating the feature. To enable it, you must also add the spring-boot-starter-shell-remote and spring-boot-starter-security.

Here's the code for the Groovy class that you can run by using the spring command line tool incantation: spring run foo.groovy:


@Grab("spring-boot-starter-shell-remote")
@Grab("spring-boot-starter-security")
@Grab("spring-boot-starter-actuator")
@RestController 
class RemoteShellFriendlyController {

  @RequestMapping("/users/{id}")
	Object someData( @PathVariable int id){
        [ someId : id ]
	}
	
}

In the screencast, I just use the default user and password. If you want use the same user and password from both SSH and HTTP, create a file application.properties and put it in the same directory as the Groovy script and put the following properties inside it:


security.user.name=youruser
security.user.password=yourpassword
shell.auth=spring
November 5, 2013

A Busy, Spring-filled November

Welcome to another installment of This Week in Spring! This week I'm in Malmo, Sweden at the fantastic ěredev conference, talking to developers about Spring, Cloud Foundry, and more! I'll be at JMaghreb next week and then at Devoxx 2013 where I'll be talking to developers about Spring, Cloud Foundry, RabbitMQ and more along with my pals Dr. Dave Syer, Alvaro Videla, and Andy Piper. Looking forward to seeing you at any of these places! Ping me on Twitter (@starbuxman) if you want to talk Spring, the cloud, big data and anyting else!

One personal highlight of Oredev, for me, personally? I got to meet Randall Munroe, creator of XKCD! I even got to hug him. I'm such a fan!

September 23, 2013

Web Messaging with Spring 4.0's Support for WebSockets, STOMP and Sock.js

Spring 4 will see some core types in Spring Integration be promoted to the core Spring framework. These types - in a new spring-messaging module - deal with common messaging idioms like a message (org.springframework.messaging.Message), a message channel (org.springframework.messaging.MessageChannel) and message headers (org.springframework.messaging.MessageHeaders)

This eventually implies a common foundation for messaging abstractions across the various Spring projects. I suspect in Spring Integration 4.0 they'll move to those core types as the primitives. It's not hard to imagine these types one day being in other messaging abstractions across Spring Data Redis, Spring AMQP, Spring Data GemFire, and Spring Integration. Right now, this gives us the ability to talk about first class support for web.next technologies like WebSockets in a future-proof API.

Spring core and web ninja Rossen Stoyanchev talks at length about some of this stuff in this blog post, Spring Framework 4.0 M2: Websocket Messaging Architectures. I think, however, you'd get a lot more by letting his kick-ass Stock Trading application do the talking. The easiest way by far is to simply run mvn jetty:run in the same directory as the pom.xml file is.

September 22, 2013

Data Integration, Stream Processing and Spring XD

The Value of Streaming Processing and Spring XD

I really enjoyed GridGain CEO Nikita Ivanov's post on Four Myths of In-Memory Computing. He nicely explains some of the applications of in-memory computing. While all his points were good, I was really happy to see him touch on stream processing as a use case.

I also think that in-memory databases are important use case? for today. They solve a specific use case that everyone readily understands, i.e. faster system of records. It?s sort of a low hanging fruit of in-memory computing and it gets in-memory computing popularized. I do, however, think that the long term growth for in-memory computing will come from streaming use cases. Let me explain. Streaming processing is typically characterized by a massive rate at which events are coming into a system. Number of potential customers we?ve talked to indicated to us that they need to process a sustained stream of up to 100,000 events per second with out a single event loss. For a typical 30 seconds sliding processing window we are dealing with 3,000,000 events shifting by 100,000 every second which have to be individually indexed, continuously processed in real-time and eventually stored. This downpour will choke any disk I/O (spinning or flash). The only feasible way to sustain this load and corresponding business processing is to use in-memory computing technology. There?s simply no other storage technology today that support that level of requirements. So we strongly believe that in-memory computing will reign supreme in streaming processing.

I've also heard this field roughly called data integration.

It's a very vibrant field. I like the way Michael E. Driscoll (@medriscoll), CEO at Metamarkets, put it:

Spring Integration makes it dead simple to integrate with various messaging systems (JMS, AMQP, STOMP, MQTT, websockets, Twitter, Kafka, etc.) to build pipe-and-filter architectures. Its API elements mirror the patterns of the same name in Gregor Hohpe and Bobby Woolf's canonical tome on the subject, Enterprise Integration Patterns. In Spring Integration, Messages flow from one component - a splitter, or router, an aggregator, a transformer, etc. - along channels. Components are decoupled in that they communicate only through Messages. Messages in turn have headers - a map of metadata about the payload - and a payload.

Spring Batch has great support for managing the state and orchestration of long-running, data-centric jobs. It has the ability to work with a variety of systems where input and output is most efficiently done in batch. Spring Batch supports the notion of jobs, which are composed of a sequence of steps. Each step can optionally read data, optionally process, and optionally write data. So, for example: one step might read data (lots of data! Millions of records! Batch will scale..) from, for example, a SQL database or a large tab delimited file. Once the data's read, a natural next step is to process it and then - once finished - write the changes somewhere.

Data integration, or stream processing, or ingestion, etc. is all about managing the integration with, and accquisition of, data from varied systems and supporting its ingestion, analysis, processing and ultimate storage.

As Nikita points out, with data storage options so cheap these days, we can record as much data as we want. The real question is: how do we process it? How do we extract value out of it? Sure, it's easy to put hundreds of terabytes of Hadoop data onto an HDFS data lake, but how do you transform that data into business value? How do you integrate with other systems - online systems, warehouses, reporting? How do you accommodate the ingest of new data even in the face of a tidal data deluge?

To do this right, you need data processing support (extraction, transformation, and loading) and a event- and messaging-centric programming model to stitch together otherwise decoupled components in distributed, messaging-centric workflows. This is where Spring XD comes in. Spring XD is a new project in the stream processing space. It builds on the strengths of Spring Batch, Spring Integration, and Spring Data and Spring for Hadoop to meet this new generation of challenges.

That picture's fairly marketitecture-ish, but it does a nice job of sort of visualizing the place of Spring XD in your architecture and in understanding it, you already understand the programming model of Spring XD: streams represent the flow of data from a source to a sink. A source is some point of entry, like a database, syslog, HDFS, etc. A sink represents the place where the data ultimately gets written to. You can put in processors along the stream to process, transform, and audit the data. A tap is a component that intercepts the data, but doesn't terminate the stream. In the integration world, the closest analog is a wire tap.

I'll let you read this introductory blog post for more.

September 18, 2013

Adding the ActionBar Sherlock Project to an Android Application

Roy Clarkson (@royclarkson) and I gave a talk at SpringOne2GX 2013 in which we talked about building REST services with an eye towards consuming those services on mobile platforms like Android and iOS. This talk demonstrates the progressive evolution of an application using Spring MVC, Spring HATEOAS, Spring Data REST, Spring Security, Spring Security OAuth, and Spring Android. The code's benefited from a lot of help from Rob Winch.

I am pulling this blog together to introduce how we used the ActionBar Sherlock project in the sample application. There is nothing here related to Spring, but I thought the whole process was hard enough that some notes might help someone else.

What is an ActionBar?

From the documentation, the ActionBar:

  1. Provides a dedicated space for giving your app an identity and indicating the user's location in the app.
  2. Makes important actions prominent and accessible in a predictable way (such as Search).
  3. Supports consistent navigation and view switching within apps (with tabs or drop-down lists).

The ActionBar, pictured above in an image from the Google documentation, provides a sort of hub for interaction UIs like menus, toolbars, etc., in your application. It's also a nice place to install a widget like a search field that can provide functionality and trigger behavior independent of any single view.

The ActionBar API (android.app.ActionBar), however, is only available in Android API level 11 and greater. There is a sort of backwards compatible API called the Android Support Library (android.support.v7.app.ActionBar) that works with versions lower than API level 11.

What is the ActionBar Sherlock?

From the ActionBar Sherlock website:

ActionBarSherlock is an extension of the support library designed to facilitate the use of the action bar design pattern across all versions of Android with a single API.

So, it provides a clean API that wraps and adapts to existing implementations if available, and otherwise does a remarkable job simulating the effect in older versions of the platform, all with no change to your code.

All of this works in a consistent way on the ActionBar. On devices that support the hardware Menu button, this menu is available using that button. Otherwise it shows up as shown here, as part of the ActionBar.

Our Sample Application

In our sample application, the user has the ability to:

  • sign in, or out of a session
  • search for records
  • update the user profile photo

Using ActionBar Sherlock

The sample application uses Android Fragments to make the layout more dynamic inside of a single Activity, so in practice there is only one Activity that needs to extend the SherlockFragmentActivity class.

To use the ActionBar, an Activity should extend one of the ActionBar Sherlock-provided Activity instances. This way, you get a reference to the ActionBar via the getActionBar() method. Conveniently, you won't really need that reference, though.

Below, I demonstrate how to setup a search field in the application. The Activity#onCreateOptionsMenu(Menu) callback method gives you a pointer to the menu reference which you may use to add menu items.

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        this.menu = menu;

        SearchManager searchManager = (SearchManager) 
               activity.getSystemService(Context.SEARCH_SERVICE);
        SearchView searchView = new SearchView(activity);
        searchView.setSearchableInfo(searchManager.getSearchableInfo(activity.getComponentName()));
        searchView.setQueryHint(getString(R.string.search_hint));
        searchView.setIconified(true);
        searchView.setOnQueryTextListener(new SearchView.OnQueryTextListener() {
            @Override
            public boolean onQueryTextSubmit(String query) {
                runQuery(query);
                return true;
            }

            @Override
            public boolean onQueryTextChange(String newText) {
                return true;
            }
        });

        // search menu item       
        MenuItem menuItem  = menu.add( getString(R.string.search));
        menuItem.setTitle(title);
        menuItem.setActionView(searchView);
        menuItem.setShowAsAction(MenuItem.SHOW_AS_ACTION_ALWAYS);        

         // ..

     }

Adding the ActionBar project to your Maven Build

I had to go through some fits to make the Android build work perfectly as the ActionBar Sherlock project is delivered as an Android .apk bundle, not a .jar. Check out the build file for the nitty gritty.

Back | Next