Category Archives: spring boot

Spring Boot is still a gem…waiting to be discovered

devnexusLast week, I had the good fortune of speaking twice at the DevNexus conference, the 2nd largest Java conference in North America. It was awesome! Apart from being a total geek fest with international attendance, it was a great place to get a bigger picture of the state of the Java community.

intro-to-spring-data-devnexus-2016A bunch of people turned up for my Intro to Spring Data where we coded up an employee management system from scratch inside of 45 minutes. You can see about 2/3 of the audience right here.

It was a LOT of fun. It was like pair programming on steroids when people helped me handle typos, etc. It was really fun illustrating how you don’t have to type a single query to get things off the ground.

platform-spring-bootWhat I found interesting was how a couple people paused me to ask questions about Spring Boot! I wasn’t expecting this, so it caught me off guard when asked “how big is the JAR file you’re building?” “How much code do you add to make that work?” “How much code is added to support your embedded container?”

learning-spring-bootSomething I tackled in Learning Spring Boot was showing people the shortest path to get up and running with a meaningful example. I didn’t shoot for contrived examples. What use is that? People often take code samples and use it as the basis for a real system. That’s exactly the audience I wrote for.

People want to write simple apps with simple pages leveraging simple data persistence. That is Spring Boot + Spring Data out of the running gate. Visit http://start.spring.io and get off the ground! (Incidentally, THIS is what my demo was about).

I-heart-spring-AidenI was happy to point out that the JAR file I built contained a handful of libraries along with a little “glue code” to read JAR-within-a-JAR + autoconfiguration stuff. I also clarified that the bulk of the code is actually your application + Tomcat + Hibernate. The size of Boot’s autoconfiguration is nothing compared to all that. Compare that to time and effort to write deployment scripts, maintenance scripts, and whatever else glue you hand write to deploy to an independent container. Spring Boot is a life saver in getting from concept to market.

It was fun to see at least one person in the audience jump to an answer before I could. Many in the audience were already enjoying Spring Boot, but it was fun to see someone else (who by the way came up to ask more questions afterward) discovering the gem of Spring Boot for the first time.

CedricTo see the glint in someone’s eye when they realize Java is actually cool. Well, that’s nothing short of amazing.

The state of Spring so far…

I-heart-spring-AidenI have never been more excited to be a part of the Spring team as I am now. It feels like we are blazing new trails left and right. Seeing the massive turnout this week for Stephane and Brian’s “Spring Boot University”, a 3-hour session at DevoxxFR, left me awestruck. Wish I could have been there.

Everywhere I turn, people are gobbling up Spring Boot. They tell me, this is what they have been looking for. How did this happen? It’s a really neat history.

A little bit of history

The Spring Framework started lean and mean. It was a fantastic way to integrate critically needed tools through its profound power of dependency injection. Some people criticized this as hype, but the community’s massive adoption proved the vitality of this approach. Coding was fun! Demo apps are one thing, but people were using Spring Framework to build large, complex systems. Complex systems need lots of components. Existing APIs like JMS, JDBC, and other things came with the need for lots of plumbing. These APIs were way too low level. And thus was born JmsTemplate, HibernateTemplate, and my personal favorite: JdbcTemplate.

But that was not all. Building web apps with Spring MVC was hot. It made testing app controllers nice and easy. You weren’t obligate to run web-based acceptance tests through complex controls. Instead, you could isolate things. Nonetheless, as the needs of the community grew, so did Spring. To help different parts of Spring grow and evolve and now slow down the core framework. other projects were formed. Spring Security, Spring Data, Spring Integration, Spring Batch, and more. At one point, people expressed their dislike for “spring.jar” containing everything. The Spring team chopped things up into finer grained JARs so you could grab what you needed. Then we had too many JARs. What?!?

As the power and might of Spring grew, so did its learning curve. People were asking which project to use. How to integrate them together. What version of Spring Integration with the version of Spring Framework I’m using? How do I even start using Spring MVC? What steps do I need to carry out?

Spring Boot is born

platform-spring-bootThus was born Spring Boot. Spring Boot brought forth a series of critical concepts.

  • Pre-pick the versions of Spring and other libraries so you don’t have to
  • Auto-configure boilerplate stuff like Spring MVC, Security, Integration, etc.
  • Remove key beans if you define your own
  • Accelerate Spring’s power of externalization of properties to Warp Factor 9!
  • Add on DevOps-ready metrics

A big hurdle was mixing together different libraries. If I have Spring Framework 4.0.1, what version of Spring Integration should I pick? Simple: pick one version of Spring Boot, and both of those dependencies are pre-picked for you. Boot doesn’t stop there. It extends into lots of key 3rd party libraries. This decision was so popular, that Spring IO was created to reach out and harmonize the versioning of 380+ libraries.

A big issue (especially for me, a non-web guy at the time), was standing up Spring MVC. First, you had to put certain bits into web.xml. Then you needed to stand up view resolvers, message converters, controllers, and a whole cadre of other components. You really needed to understand Spring MVC to do it and to do it right. Spring Boot stepped up to the plate and said, “don’t worry, we’ve got you covered”. Add “spring-webmvc” to your project, and Boot will create all that stuff for you. You just create a controller that returns view names, and you’re up and running.

danielskullNo form of automation can ever cover every circumstance. Sooner or later, developers need to break out of the framework’s default position. And this is where LOTS of tools fail on a massive scale. There are two common outcomes: 1) Don’t permit such customization and hamstring future developers or 2) Add so many extension points that the simple use case vanishes. Spring Boot introduces option 3) Drop bits of auto-configured stuff when you create your own. This is known as backing off, and has moved the bar forward on app and framework development really far. New applications and new frameworks will surely adopt this approach to expansion because it just makes sense. If you build a framework and don’t shoot for this, someone starting after you might catch up and pass you because they will.

Something I’ve needed for years before I wrote Java for my day job was externalization of application properties. I dealt with development, test, and production environments. Rebuilding apps for each target was wasteful. So I hand wrote code for that. Spring Framework has always had powerful support for properties files, but Spring Boot took that feature and accelerated the options. Having APP_ENV and -Dapp.env both map to @Value(“${app.env}”) String appEnv or class ApplicationProperties { public void setAppEnv(String env)… } is sheer genius can cannot be understated. People talk about 12-factor apps and high tech wwizbang manifestos, but this concept is simple to grok and applicable just about everywhere. You could be running a close network solution (which I did at my old job) with no cloud involvement and find this technique the Right Thing To Do.

DevOps-ready controls and metrics is something area always begging for. System administrators, program managers, business analysts, and others are always asking for this extra metadata about our apps. Being able to spit out a first cut of this by simply adding one dependency to an application is phenomenal. Then being able to craft your own metrics and controls with little effort ramps your app up to production ready and Management Friendly by providing them the warm fuzzy metrics for clients without breaking the bank of technical debt.

Where are things now?

With Spring Boot spreading across the Java ecosystem over the past two years, it really is exciting to see how much fun people are having building apps. They focus on the end game, not setting up infrastructure. Hearing chatter like “Using Spring Boot is like pair programming with the Spring team” (@starbuxman) and “Spring Boot is just what we need” is cool. I get excited to go the Nashville JUG and talk about some piece of Spring, not just because it “looks good”, but because I can sincerely point out how using it is simply fun! Isn’t that what real software is supposed to be? Functional, carries business value, and at the same time, fun to build and release? It almost feels like Spring Boot introduces yet another rennaisance to application development.

3021OS_mockupcover_normalI have been quite pleased that my previous book, Python Testing Cookbook has earned double the advance over the past three years (and keeps making me money!) But I jumped out of my chair when the first statement for Learning Spring Boot came in last month and showed that over 400 people had bought a copy. My excitement to write about Spring Boot was paralleled by my instinct that people would want to learn about Boot’s secrets.

There is a lot of action happening in the Spring team as we continue to blaze trails we couldn’t foresee five years ago. Many of our key decisions in the past have put us on a strong  footing to continue pushing the envelope for the future in both application power as well as ease of development. The community experience of putting out new features, getting feedback, and generally building something better each and everyday that helps thousands of people solve problems is both inspiring and humbling. There’s no other place I’d rather be working.

Happy coding!

Despite being buried at #s2gx, managed to submit chapter 1 rewrite for “Learning #SpringBoot” to @PacktPub

learning_spring_boot_ch1_odtThere was a mix-up of communications with my editor. I told her that I was out this week. But it appears that just won’t cut it. Packt Pub is FAST! Thankfully, I invested time during last night’s flight to work on Chapter 2 – Quick Start with Java. This morning, after fixing up Spring-a-Gram, I was able to polish up and submit the rewrite for Chapter 1 – Quick Start with Groovy.

Word is that they’ll actually have this book out sometime in October. Wow! Everyone I talk to is stunned at the speed this book is being cranked out. I have become very glad that my other TWO talks I submitted for SpringOne did NOT get approved! When would I have time considering I still have to prep slides.

As a side note, I also SUPER glad to have used asciidoctor. It made edits super, super, SUPER simple to deploy. Stay tuned!

That’s a wrap! “Learning #SpringBoot” ‘s 1st draft has been submitted to @PacktPub

learning-spring-boot-ch-5Last night, I worked from 9:30pm until 2am on Learning Spring Boot. Whew! It was tough work, but I needed to pull it across the finish line. I had the code lined up quite nicely for the entire chapter. I simply need to tell the story of how all this stuff worked together.

As I’ve said before, security by itself is complicated. There is a lot of fine details involved. When someone first starts reading the reference docs of Spring Security, it can get real intimidating real fast. That isn’t Spring Security’s fault. It’s inherent to the nature of locking something down except for the right people in the right context with the right protections. “right” and “wrong” can be very hard to define in just a couple sentences.

I tried to walk through what is happening, provide a little “why is this happening” and finally leave some links for those that want to dig a little deeper and understand the incredibly complex stuff that Spring Security is ACTUALLY doing for them. The protocols Spring Security picks up and handles are quite complex, and when you get to the end, I hope the reader has a strong appreciation for how simple Spring Security has made it to give the developer control while still protecting system integrity.

With all that said, I breathed a big “whew!” as I bundled up this chapter’s manuscript and emailed it over to my editor at Packt. I have already started receiving feedback on the other chapters from my review team. These people are sharp! They really know Spring and have spotted some sloppy mistakes on my part. After I parse all their comments, this should be one well honed book!

asciidoctorI also have truly enjoyed the development process of this book. Writing it in asciidoctor has let me focus 95% of my effort on the content. I work with an IDE open so I can tweak the code, run it, tweak again, and then commit the changes. My manuscript simply includes code files and fragments, and I layer it with some prose to explain what is happening and why it’s happening. Here and there I put tips and notes to answer questions I can foresee.

Then on the command line, I constantly regenerate an HTML rendering of the book. I read through it in chunks and polish it up. After all is done, I finally open up the LibreOffice output and and walk through to fine tune bits of code that overrun the width of the page. By staying away from the word processor as much as possibly, the integrity of this book’s content has been kept at what I feel is tip-top shape.

Chapter 5 of Learning #SpringBoot almost done!

This Thursday I’ll be submitting the first draft for Chapter 5 – Securing Your App with Spring Boot inside Learning Spring Boot. If you have no experience with Spring Security, then I hope you’ll enjoy this chapter. Security by itself is a complex topic. There is no single thing that instantly makes your entire application secure from everything.

Spring Security is a powerful application level security tool. You get very detailed control and can customize to your heart’s content. But as is often the case, people want to use some basic settings that enact a common security model: authentication and authorization.

When you add Spring Security to a Spring Boot project, things get automatically locked down. This is handy for demos, but this chapter will show you can then go in and configure things more to your liking. My plan is to walk through in-memory based options (good for testing and getting started) as well as a configuring a couple different databases that are commonly used. With that sort of introduction to Spring Boot + Spring Security, it becomes much easier to read the online reference docs if you want to cut over to an LDAP-based user data store.

As I said earlier, security doesn’t start and end at the application level. I want this chapter to be comprehensive in the sense that security doesn’t end at the application level. Spring Boot does a fantastic job of inverting the concept of a container by having the app bring along embedded Tomcat to run itself. In this chapter, we’ll see how to configure Spring Boot’s embedded Tomcat servlet container use SSL, strengthening the end-to-end security of your app.

docbook…what a piece of junk!

lukepieceofjunkIn the past week, I have focused on porting the Spring Data Evans release train to asciidoctor. It has been joyous and torturous. The joy is moving away from docbook and towards asciidoctor. The torture is dealing with all of docbook’s idiosyncrasies and the wonderment at how someone could build such a tool in the first place.

First of all, XML is a highly nested data structure. The nesting is used to convey semantics, but XML was originally designed as a machine-to-machine communication medium. It was indicendtially written using ASCII so that devs could debug the communications more easily along the way. Using it to create documentation systems is ridiculous.

docbook-whitespaceIf you look at this fragment of docbook, you can see all the wasted space based on standard XML formatting. Reading and maintaining this is an eyesore and the source of carpal tunnel.

asciidoctorLooking at asciidoctor is much more pleasing. There is no cognitive overhead of angled brackets. No extra indentation. And the results are easier to visualize. The semantics are so much clearer.

But that isn’t the only thing that has been a hassle. To do this migration, I wrote a SAX parser that properly pushes and pops as elements are started and finished. In essence, as you start a new element, a new state needs to be created an pushed onto a stack. When that element finishes, you pop that state off the stack, and properly append it to the previous state, i.e. the enclosing XML token. I had this working smoothly. Along the way, if you hit any characters between the XML entities, they need to be appended to the top of the stack’s “chunks”.

But docbook has so many awkward situations, like <section> <title>blah</title> <para> <section> <title>blah</title>…., that would lead to a level 0 header followed by a level 2 header. Where is level 1? Nowhere to be found and up to me to clean up.

Also docbook has SO MANY different tokens that really expresses the same thing. For every different element type, I created an AST node to represent it. But when it came to <code>blah</code>, <interfacename>blah</interfacename>, and <literal>blah</literal>, I created only one, Monospaced. These all basically get converted to the same thing: `blah`, i.e. some text wrapped in back ticks.

Other stuff is simply impossible. I did my best to handle tables, but too many quirky things can go wrong. So I did my best and then hand edited after the fact. Callouts are worse. Asciidoctor makes callouts awesome. But getting over the hump of docbook’s format is such that I don’t even try to convert. I just stuff the raw AST content in the output and warn “DO THIS PART BY HAND”.

Given all this, porting the whole documentation of Spring Data to asciidoctor required me to invest three days of effort purely at building this script. I actually rewrote the script after Day 2 because I had made a fundamental flaw. But I met my objective of migrating all of the Evans train by this past Monday.

But the pay off of writing the script properly has been great. I hadn’t written a SAX parser like this for ten years. It brought back keen memories. Thankfully, using Spring Boot CLI + Groovy made it a pleasant, scriptastic experience.

 

Chapter 4 of Learning #SpringBoot submitted…upgrading manuscript to 1.1.5.RELEASE

learning-spring-boot-ch-4Yesterday afternoon, I bundled up Chapter 4, Data Access with Spring Boot for Learning Spring Boot and shipped it off to Packt Publishing. They were happy to receive it on time.

Then I saw Spring Boot release version 1.1.5.RELEASE. I just updated all my source code to the latest version, edited the fragments, and fixed the links in my asciidoctor files. Reading through all the issues of this release, nothing appears to be of any impact to this book.

Naturally, I’ll recheck everything after I wrap up Chapter 5, Securing Your App. In the next and final chapter, I’ll show how Spring Boot speeds up securing apps. By merely adding Spring Security to your classpath, Spring Boot leaps into action and locks things down with suitable defaults. You can easily alter various settings. Finally, you can start plugging in custom configurations as needed.

secure-ssl-appSecurity, in my experience, has historically been a tricky subject. I’ve seen countless teams apply security as the last step. People also don’t understand that security is a multi-layer effort. It’s not ALL contained in the application.

And security requires a certain understanding; a frame of mind. When I worked on the commercial engineering team a couple years ago, I applied several strategies to prevent users having their data compromises. Not all of these ideas were my own. Many came from a teammate that had a prankster’s perspective.

If you look at the second image in this blog, you’ll see a perfect depiction about how people will do something like configure SSL for a website and call it a day. SSL only secures one aspect of things. Usernames and passwords only cover a few more aspects.

This chapter will help cover how Spring Boot makes it much simpler to secure the embedded Tomcat servlet container. It will show how to institute authentication and authorization to verify you are who you say you are and that you’re authorized to do what you must. It’s important to plug in security from the get go, and Spring Boot makes this even easier than ever. But never stop looking for attack vectors that you must block to avoid issues.

 

Chapter 4: Data Access with #SpringBoot on the move /cc @PacktPub

learning-spring-boot-ch-4I’ve gotten things moving quickly with chapter 4 of Learning Spring Boot. The general idea is that I want to show how to get off the ground super fast using Spring Boot and H2 as an in-memory database. Give the user the tools to either load up some sample data with a SQL script or with the Spring Data APIS. And then from there, see how to transition to production data.

You see, a common problem people deal with is building code on their development workstation and wanting to write unit tests. But the database is a fixed source of data. What do you do? Wipe it clean before every test run? What about other developers? That’s where in-memory, local database really shine. They are fast, have zero setup, and when you shutdown the test app or test case, everything is clean.

So using that to write code, test cases, etc., is great. But eventually, you have to switch over to pointing at a development database, perhaps a test bed database, and ultimately, a production database. Your app shouldn’t have to go through crazy gyrations and edits to move between those different environments.

And that’s the story I want to tell in this chapter. Spring Boot + Spring Data + Spring Framework makes this so incredibly easy. It’s a problem I ran into several times in the past, and with the über awesome power of Spring Boot+Data+Framework, I want to show my readers that there is no reason to fear the multi-environment database setup!

Chapter 3: “Debugging and Managing your #SpringBoot app” underway

learning-spring-boot-ch3Last Friday, I submitted the 1st draft for Chapter 2: Quick Start with Java inside Learning Spring Boot. In that one, I walk through the detailed steps of crafting an app that scans for open issues against multiple GitHub repos using several Spring projects.

With that behind me, I am now diving into Chapter 3. In this chapter, I want to help any developer understand what Boot is doing, how it does it, and basically give them all the tools needed to debug and manage a Boot app.

Long ago, I remember Spring and it’s auto-wiring. This code was deemed by many as too magical, only good for toy apps, certainly not for production, and generally something that more of a trick than of real use. Today, that is no longer true. Instead, auto-wiring is recognized as a valid technique. I see it used all over the place including the app that runs http://spring.io.

I have been worried that Spring Boot might accidentally get dubbed as another form of magical code. The way it works is actually quite simple, once you understand it. Or shall I say, once I discovered how it worked last year, I sat down and quickly wrote up auto-configuration support JMS and RabbitMQ before I left the SpringOne conference. Heck, I even felt motivated to write a blog post!

So before anymore delving into what you CAN do with Spring Boot, I wanted to devote a chapter on how to debug apps and not get surprised or caught off guard.

Spring Boot has one tangled issue being worked on. There is no simple way to extract ALL the property settings or flatten out ALL the switches and flags of how Boot auto-configures things. In fact, other teams outside Spring and Pivotal are starting to create their own auto-configuration hooks as well.

You can get really far with the reference docs. But in my opinion, sooner or later, devs will have to look at the source code. My goal is to help decrypt that process and show how simple it really is.

Chapter 2’s first draft is roughed out

ch2_fodtLast night, I finished up the last bits of chapter 2’s first draft. I like to knock out a chapter in the rough and then go through it, applying bits of polish. For me, it’s always easier to polish something that already exists.

My biggest concern was the fact that Spring Boot keeps taking away space filling code! So instead of creating some boring toy app, I had to think up something bigger. I figured an app that scans open issues from multiple GitHub repositories (part my upcoming webinar on creating management apps with Spring Boot) would be good enough. Wrong!

This chapter’s demo app has become way too small! Ever hear of that? Our apps usually are too big, especially for the medium of print. I tried to fill up the allotted space with deploying to one of the fastest growing PaaS’s out there: Cloud Foundry. There are over thirty members of the Cloud Foundry Foundation, so showing how über easy it is to push your Boot app up to a cloud should eat up space, right.

Wrong again! Well this has forced me to roll up my sleeves and actually write some pragmatic support scripts that load the system down and gather metrics at the same time….using Spring Boot!

So after slaving away at creating useful code, deployed to a useful platform, with useful support, I figured any more content and this chapter would explode in practical density. I saved my last changes and decided its time to now go through and polish things up. There’s always an opportunity to add another chapter later on, right?

It’s nice to read through the manuscript and see if it flows. Am I going to fast? Too slow? Sometimes its a mix of both. Given that this will be THE first Spring Boot to hit the proverbial shelves, I want it to be a good reading experience. I also ponder what questions the reader might be thinking, and try to insert pull-outs answering them.

I’m also incredibly happy that I was able to get a functional Asciidoctor backend written AT THE SAME TIME. Don’t worry, I drink plenty of coffee in the morning to recover from my total lack of sleep. 🙂

Stay tuned for future developments!