Category Archives: spring boot

Streams of messages are the way to go

I have been diligently getting all my code up to date for the release of Learning Spring Boot 2nd Edition this September. Digging into Chapter 8, WebSockets with Spring Boot, I realized I had a bigger challenge than expected.

You see, I’d chatted with Rossen, the lead developer on Spring Web. In the past, his job was overseeing Spring MVC, but in the past year, that has expanded to our new Reactive Streams story and the module Spring WebFlux. In short, Rossen informed me that there was no messaging available with WebSockets in WebFlux.

I’m not sure you’re aware what this means. “Message” was a paradigm invented by Mark Fisher in the early days of Spring Integration with a nice little container class called Message<T> that included a payload and optional headers. This was handy when it came to enterprise service buses, but people spotted the paradigm as more universally applicable.

Hence, they put a messaging layer on top of WebSockets, making it super easy to pipe messages from clients to the server and back. Anywhere in the server side code, you can get your hands on a SimpMessagingTemplate and publish a message, targeted for either a server side or client side endpoint. The runtime would handle it all.

And none of this was available with Spring 5’s WebFlux-based WebSocket solution. As Rossen said, “think of it as streams of WebSocket messages.”

That was tricky.

So I dug in and started learning the API. In the reference docs, they show how to register a WebSocketHandler. You tie that API to a URL and inside the API, are handed a WebSocketSession. I kind of stared at this API for five minutes before noodling around with it.

Unsure about what to do, I cracked open the Spring Framework source code and started reading their unit tests. Since my chapter had a “chat” server (the de facto demo for WebSocket technology), I was ecstatic to see something similar right there in WebFlux’s unit tests. It was an EchoServer.

I copy and pasted the code into my book’s code. Tweaked the JavaScript to hook up. Fired things up, and started sending in messages. And it worked.

Until I opened a second tab sporting a different WebSocket session. That’s when I noticed that the messages posted by one tab didn’t appear in the other.

And then I KNEW what they meant by “EchoServer”. Receiving the messages on a session and sending them right back ONLY WORKS ON THE SAME SESSION.

I shook my head, remembering the fact that Spring 4’s WebSocket configurations SHOWS you configuring a broker. That’s what is needed!

I needed a broker and I didn’t have one. At this point, I had gotten barebones WebSockets registered on the server and my client connected. But to noodle this thing out, I stopped to get a coffee. As the java was brewing, so was my noggin. That’s when the light bulb went off.

I already had a broker. It was right there.

You see, I had gambled on putting Spring Cloud Stream in my book when it was in its infancy. In Chapter 7, AMQP Messaging with Spring Boot, I kick things off with Spring AMQP’s RabbitTemplate, which is great for small stuff. As if often the case Spring’s template approach makes the AMQP APIs very pliable. They also adopted the Message paradigm from Spring Integration so you can either send your own POJOs, or you can do it Message<Pojo> style, which moves your abstraction up a level, making things simpler.

But Spring Cloud Stream is even better. It moves things up even higher. You aren’t thinking in terms of message brokers. Instead, you are thinking about chaining together streams of messages. (Which, by the way, dovetails PERFECTLY with Reactor).

Whether you are using RabbitMQ or Kafka (or whatever) is simply an implementation detail. With a few property settings, you can put together any sort of messaging you want.

And I was already doing that!

Now I’m no genius. This is stuff that had I just spoken with Rossen and Marius (lead for Spring Cloud Stream) they would have pointed out in no time. But there is that thrill of discovering something for yourself that is unbeatable.

So I hammer away at a service that listens for WebSocket messages and pipes them into a broker via Spring Cloud Stream. (Thanks Artem for showing me to do THAT with Reactor!) I code another Spring service that listens for a stream of messages coming from the broker and pipes them out to a WebSocket stream.

And I’m done. In maybe 20 minutes. (I did goof up by not pointing these two servers at the same AMQP exchange).

I fire up my system, and the chat service is working. Flawlessly. A message written in one tab is shipped over a WebSocket to the server. The server pipes it into RabbitMQ. The other service scoops up the message, and pipes it out to the WebSocket client. And this is happening for every WebSocket session that has registered. This thing is a knockout punch, because I knew I architected it right.

Poof! (Plus, the concept feels totally righteous. Streams of messages, flowing through the system.)

That’s when another realization hits me. When I previously drafted this chapter, I attempted to use Spring WebSocket’s RabbitMQ option, but never could get it to properly bind to my RabbitMQ instance. Sadly, I switched to their in memory broker. This meant the solution wouldn’t work if you ran multiple instances in the cloud.

THIS SOLUTION WILL!

Because it’s piping stuff right into RabbitMQ, it will work perfectly. (Partly thanks to Consumer Groups).

To wrap up the chapter, I even went so far as to show off SimpMessagingTemplate’s sendToUser API. It nicely lets you send a message to a single user. I coded a little “@bob Did you get this?” magic, where it would parse the @’d user, and then convertAndSendToUser(parsedUser). Well, I had none of that API, remember?

How can I pull this off? Must be too much, right? Wrong! Since every message is traveling to everyone, and it’s using the Message<T> construct, it takes no effort to add a header including the original user’s name.

The broker-to-client service can simply parse the message and compare against the user or themselves, and decided whether or not to let it on through. (Send a copy to both parties!) It’s basically an extra filter layered on top, which is why Reactor makes this type of thing so easy to apply.

Anywho, with a solid day of work, I manage to code the entire thing, top to bottom, using RabbitMQ, WebSockets, Project Reactor, and even have user-to-user messaging. Freakin’ wicked it was to put it all together.

And I know this is rock solid not because of what I coded. But because of the powerful underlying concepts orchestrated by Rossen, Mark Fisher, Artem, Gary, and Marius.

Can’t wait to apply security filtering in the next chapter to these WebSocket streams.

Learning Spring Boot requiring more tweaks to get off the ground

With things bearing down on my September due date for Learning Spring Boot 2nd Edition, I’ve gotten in gear and started hammering at the codebase.

For one thing, I have strived to catch up ALL the code to Spring WebFlux, no longer using the servlet-based Spring MVC. In the process of doing that, I discovered a breaking change in Spring Framework that conflicts with the latest milestone of Thymeleaf. I switched to snapshots, and moved forward.

The big change coming down the pike has been WebSocket support. In Spring 4, there is incredibly detailed support for various messaging protocols, messaging brokers, and all sorts of goodies involving Spring’s WebSocket support.

With Spring WebFlux, they had to start from scratch and build things up. Suffice it to say, streams of WebSocket messages in and out has a very basic API. Hence, I’m rewriting the code in Chapter 8 to leverage this, chuck aside things like STOMP and SockJS. I rewrote the server side code thanks to the project lead of Spring Integration, and revved up to test it out, only to get stymied by something else.

Somehow, Reactive Web was switched off in favor of Servlet Web.

Huh???

Spending a couple hours on Slack with some super sharp teammates, I uncovered a dependency from Spring Cloud Netflix that pulled in Tomcat along with another transitive dependency on Spring MVC. Excluding them got things humming again on Netty, only to find a bug in Thymeleaf caused by Spring WebFlux + Spring Cloud Stream.

Sigh. I updated the issue filed with Thymeleaf asking about another release to see how to move forward. Until then, this book is paused. Yet again.

When that is fixed, hopefully I can push forward and get the last bits in line.

Cheers!

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!