Raible Designs

My Marvelous Road Trip to the Utah JUG

Matt Raible — Wed, 22 May 2024 09:35:09 -0600

I have many fond memories from speaking at the Utah JUG over the years. I fell in love with Utah when I worked at Overstock in 2011 and experienced the greatest snow on earth. It's wild to reminisce about 2018 too. I spoke at the Denver JUG on Wednesday, then woke up early on Thursday and drove eight hours (through multiple snow storms) and made it 15 minutes before my talk. I lost a windshield wiper in the process and didn't have time to replace it, so it permanently etched a line in the vehicle's windshield. In February 2020, I did a Rocky Mountain JUG tour with Ray Tsang. That's when I learned that Ray is really good at pool.

Because of these experiences, I always jump at the opportunity when I'm invited back. This year, I decided to take my time and do a road trip in my trusty VW Vanagon (Stout) to Utah. I planned to mountain bike in Fruita and Moab along the way, then ski at a couple Utah resorts before returning home.

I was pleasantly surprised when I saw a storm coming the night before my departure on April 16th. I quickly altered my plans and fell into an 18" powder day at Copper Mountain on Tuesday morning.

That afternoon, I drove to Fruita and went for a mountain bike ride on 18 Road. There are not many places where it's possible to have an epic powder day and do an awesome mountain bike ride in the same day. I love Colorado!

I camped in Stout that night and woke up to a beautiful desert morning. After some coffee and oatmeal with raspberries and walnuts, I headed for Moab.

I stopped at Klondike Bluffs for a 16.2 mile ride that took me 3½ hours. I was gassed at the top but thoroughly enjoyed the views.

I finished driving to Salt Lake City on Wednesday afternoon. I'm always impressed with how close, and gorgeous, the mountains are to the city.

On Thursday morning, I released a new version of the Micronaut blueprint for JHipster, then hit the slopes at Snowbird. The weather was fantastic for spring skiing.

I made sure to get some runs in at Alta too.

I dressed up as an old-fashioned Java developer on Thursday evening and headed to the Utah JUG meetup at Lucid's Global HQ. I was pleasantly surprised to see a full room of Java enthusiasts. Before my talk, Jason Porter announced that it was his last meeting as President of UJUG. He served in this role for 11.5 years and was amazing at it. Congratulations on your retirement, Jason!

I spoke about Micro Frontends for Java Microservices and used JHipster to demonstrate how it all worked.

Kudos to all the fabulous developers who attended the @UtahJava meetup tonight and listened to me ramble on about micro frontends and @jhipster. You can find my slides on @speakerdeck:

🏔️? https://t.co/Kp19jjOG8E #microfrontends #jhipster #react #modulefederation pic.twitter.com/W7tF7pUxpt
— Matt Raible (@mraible) April 19, 2024

My slide deck was similar to the one I delivered at Devnexus the previous week, with minor enhancements.

I received a lot of positive feedback on LinkedIn after my talk, particularly from college students that Jason had invited from his alma mater. This put a smile of satisfaction on my face well into the evening.

On Friday, I woke up early to get a start on my road trip home. I was originally planning to ski another mountain in Utah, but realized I could make it to Steamboat by noon, and chose that route instead. Stout's red-blinky-light alerted me that something was wrong when I stopped at the gas station. Two quarts of oil fixed things and I was on my way. The open road with minimal traffic was wonderful.

I arrived at Steamboat around noon, just in time for spring skiing in a t-shirt.

After Steamboat, I headed to our Ski Chalet in Winter Park for the weekend. Friends joined us for an end-of-ski-season celebration in Mary Jane's Challenger lot on Saturday morning.

Sunday was a sunny, bluebird day. The kids and I ended our ski season with a final run down Trestle and a stop at the treehouse.

More photos on Flickr → Road Trip to Utah JUG 2024

I arrived home late Sunday night. I'm proud of Stout for successfully completing the trip. Now I have even more fond memories of speaking at the Utah JUG. Thanks to Jason Porter, Don Bogardus, and Jonathan Bronson for the opportunity! 😊

A Delightful Trip to Devnexus

Matt Raible — Sat, 11 May 2024 10:27:21 -0600

Devnexus is one of my favorite conferences in the world. I have many fond memories of attending over the years and some awkward ones, too. My first memory is when Micah Silverman and I worked at a Stormpath booth there in February 2017. Okta had just acquihired us and we weren't allowed to talk about it. We encouraged folks to sign up for our service even though we knew signups would shut down at the end of the week.

It's funny how life comes full circle. My employment with Okta officially ended the week before this year's Devnexus. I tried to cancel my talk when I first got the news, but Vincent and Pratik convinced me to go, and I knew it would be good for networking. I'm glad I did because I had a blast! It all started on Monday, April 8th.

The @devnexus adventure begins! pic.twitter.com/J3bfOQrh8k
— Matt Raible (@mraible) April 8, 2024

I was in a tremendously good mood when I took this photo. I was sporting a new DU hat in anticipation of their NCAA Frozen Four victory the following weekend. And I was on my way to what seemed like a college reunion. I've been a part of the Java community for over 20 years, and many of the speakers are old friends whom I've made a lot of memories with.

Tuesday, April 9

The first day started off with a JUG Leaders Summit. The two presentations I really enjoyed were from Jorge Cajas and Ari Waller. Jorges talked about getting students and younger people involved in JUGs (Java User Groups) and encouraged beginner talks.

Advice from @cajasmota for getting students involved with JUGs:

- Offer beginner topics
- Organize meetups oriented to students
- Keep in touch with professors
- Don't forget that they are kids#devnexus #jugleaders #java pic.twitter.com/Bg76D8goGb
— Matt Raible (@mraible) April 9, 2024

The Denver JUG used to have two talks at every meeting. The first was a basic concepts talk, and the second was more advanced. Over the years, we did away with the first talk in favor of one main talk and more networking afterward. Jorges pointed out we often expect developers to know Java frameworks when many of the younger developers have never used them.

Ari talked about an AJUG initiative to support qualified global JUGs by providing a paid Meetup Pro account. This is also part of an effort to bring visibility to the greater Java community and it will be called the Devnexus Java Community Meetup Pro Network. I'll update this post when I have more information.

That afternoon, we had a Java Champions Summit. We discussed many topics, and we've since scheduled more time to talk virtually later this month. The photo below from Ken Fogel captures that we had a lot of Java leaders in attendance!

Wednesday, April 10

Pratik and Vincent kicked off the <dev/>olution on Wednesday morning. Amazingly, they've been doing it for 20 years!

I did an interview with Baruch Sadogursky at Gradle's Build Propulsion Lab after the opening keynote. We talked about developer productivity, open source, Develocity, and JHipster.

I also did an interview with Melissa McKay at the DevOps Speakeasy. We talked about my session, Micro Frontends for Java Microservices.

That afternoon, Sharat Chander's keynote about moving Java forward together contained wisdom he learned from his father.

"Speed, at a certain point, becomes harm. Instead, move thoughtfully and build things." -- @Sharat_Chander at #Devnexus #Java pic.twitter.com/fYatiUX5cu
— Matt Raible (@mraible) April 10, 2024

I talked with Sean Phillips the night before. He dazzled me with his enthusiasm for fighting back against bad actors with his Trinity project. I was not disappointed during his talk and thoroughly enjoyed all my conversations with him and his lovely wife.

This was an awesomely energetic talk by @SeanMiPhillips! I enjoyed it immensely. Check out his Trinity project which can detect AI-generated audio in minutes. Built with JavaFX.https://t.co/X9EuhNEmIg

Release for @devnexus: https://t.co/cHnChwLUIY https://t.co/yiBEEx06aV
— Matt Raible (@mraible) April 10, 2024

Seeing so many old friends at the conference before the social activities that evening was awesome.

A lot of good friends and #usualsuspects are at #Devnexus this year! ❤️ pic.twitter.com/7poa8ARQh2
— Matt Raible (@mraible) April 10, 2024

Thursday, April 11

I prepped for my talk Thursday morning, practiced my demo, and dressed up as an old-fashioned Java developer. My talk had a full room and I finished right on time. The demo worked flawlessly, so I was quite pleased. You can find my presentation on Speaker Deck.

That afternoon, I hung out with Josh Long and met Chris Bono. We had cocktails at White Oak and had a fun time talking about Spring, life, and our fantastic children. From there, I reunited with former colleagues Brian Demers, Randall Degges, Micah Silverman, and others at Cuts Steakhouse. I sat next to Jonathan Schneider from OpenRewrite and learned a lot. I was impressed to learn that OpenRewrite is used to upgrade applications between major releases, and some folks have used it to migrate from one Java framework to another.

Friday, April 12

The conference ended on Thursday, and Friday was a designated Speaker Day. We gathered at Cabbagetown Park for a few hours of volleyball, reminiscing, and recovering from the week of intense social activities. That evening, we headed to The Painted Duck for some duckpin bowling. It was a lot harder than regular bowling, yet fun was had by all.

Fun times duckpin bowling with @devnexus speakers! 🦆pic.twitter.com/JMz2zChMST
— Matt Raible (@mraible) April 12, 2024

If you ever get a chance to attend or speak at Devnexus, I highly recommend it. It's a well-run show, and the community vibe is wonderful. Thank you, Pratik, Vincent, and the Atlanta JUG team!

The JHipster Mini-Book v7.0 Released!

Matt Raible — Tue, 7 Mar 2023 15:43:37 -0700

The JHipster Mini-Book v7.0 is now available as a free download from InfoQ. Get it while it's hot! 🔥 You can read more about this release on the JHipster Mini-Book blog.

The source code for the application developed in the book (21-Points Health) is available on GitHub.

Thanks to the InfoQ publishing team, Jeet Gajjar for tech editing, Maureen Spencer for copy editing, and Ana Ciobotaru for publishing it to production.

And most of all, thank you Asciidoctor for making the publishing process so easy!

Questions about JHipster, JHipster Lite, and Spring Boot 3

Matt Raible — Wed, 14 Dec 2022 08:07:27 -0700

I'm a big fan of LinkedIn. I'm biased because I worked there from 2007-8, have alumni privileges like a free pro account, and learned how to unsubscribe from all their emails over a decade ago.

I communicate with a lot of developers via LinkedIn. I recently received a message from Raymond Meester about the JHipster project. Raymond asked many poignant questions, and I thought it'd be helpful to share my responses with y'all. Of course, I got permission from Raymond before posting this. You can find his blog on Medium.

Hi Matt,

I was reading through some threads on the dev mailing list:

https://groups.google.com/g/jhipster-dev

I'm not part of the dev team, but I thought I just share some of my thoughts with you.

On the mailing list, there is an interesting discussion about JHipster vs JHipster Lite. Personally, I don't fully understand the debate. In my opinion, there could be one base that could be used for several kinds of generators. Say:

- Catered (default)
- A la carte (lite)

As far as I can see (at least that's the case for myself), I have more use cases for the first than the second. Just a generator with a few questions on what type of application and then the frameworks to choose (like Spring/Quarkus/Micronaut for the backend and Angular/React/Vue for the frontend) is enough in most cases.

Now that I am more experienced, I definitely want to use lite as well. It's an exciting project with some smart choices, but I don't think that it will become the majority of the users.

I do think JHL can be a new base for the normal JHipster as well. Only the generator (whether it's the CLI or GUI) on top of it will be different.

JHL could also provide a simple generator where I have the top three choices for a specific technology. Of course, when the architecture of JHipster Lite is set up well, it will be easy to add other choices (by blueprints) or change the default top 3 when popularity of a frameworks changes.

Currently, as far as I can see, there are two separate teams improving both JHipster and JHipster Lite. Good to try out different directions, but in the end, a waste of resources.

What I currently miss in JHipster (the main project) is regular updates. As an end user, I just want the latest versions when generating a new application, but lately there are huge gaps of three months between releases.

I really would like to see a monthly minor version with just dependencies updates (I understand that there is more to be done for major versions like the transition to Spring Boot 3. But even when nothing big changes it is good to have the latest libraries).

I agree with how Julien originally set up JHipster as simple as possible for end-users. But currently, Deepu seems one of the few that still stresses this point.

JHipster as it evolved is not only practicable to try out different frameworks, but also as a base for further development. Contrary to what seems to be the current belief about JHipster, it's not the speed, ease of use or the choices of generation that is the most important feature, but more that for the generated application the architecture is sound, a lot of best practices are used and the code is clean. This saves so much time for me as developer later on.

I also have a question about JHipster Native now that Spring Boot 3 has arrived. Spring removed the Spring Native library, which is not part of the framework itself. What does this mean for JHipster Native?

Keep up the good work!

This was a heavy message to receive early on a Tuesday morning. It was heavy because Raymond's questions were exact, and I thought they deserved a similar response.

> Currently, as far as I can see, two separate teams are improving both JHipster and JHipster Lite. Good to try out different directions, but in the end, a waste of resources.

Possibly, but as far as I can tell, the same people aren't working on the same project. I believe that JHipster Lite was created because Pascal and others understand Java better than JavaScript, and they were lost in the JHipster codebase and wanted a Java version. JHL also emphasizes DDD and is not interested in CRUD, AFAICT.

In reality, I think many of the contributors have had difficulty figuring out how things work. However, we've always had JavaScript heroes to bail us out. In the beginning, Julien knew everything, so he could fix things quickly. Then, it was Deepu - who has admitted to me he rewrote the JHipster core a few times when he was super active. Now it's Marcelo, and I think he's doing a great job.

I don't really look at the JHipster Lite project. I haven't even watched Julien's video from Devoxx, though I've been meaning to.

Marcelo, myself, and many others have done a lot with JHipster in 2022. I've focused on getting popular blueprints in good shape rather than the core. We've released the Spring Native blueprint this year and updates for Ionic and React Native. There's also been quite a bit of work done on the Quarkus and Micronaut blueprints, and I believe those are just a few hours away from new releases.

> What I currently miss in JHipster (the main project) is regular updates. As an end user, I just want the latest versions when generating a new application, but lately, there are huge gaps of three months between releases.

Three months between releases seems pretty good to me! If you're just looking for dependency updates, you should be able to do some of those in your project w/o relying on a new version of JHipster.

I started updating the JHipster Mini-Book in March of this year, and the current 7.9.3 version is the first version that's bug-free enough for me to complete the updates.

> What does this mean for JHipster Native?

It means it's only necessary for JHipster apps with Spring Boot 2.x. JHipster 8 apps will have native support by default since it's built-in to Spring Boot 3. Related to Spring Boot 3: we started upgrading in late September, and I believe we've made great progress. In the past, it's taken us six months to a year to upgrade between major Spring versions. I tweeted our current status recently.

Raymond and I had a bit of back and forth regarding upgrades.

I also think you missed my point on upgrading JHipster on a regular basis (say, a monthly interval).

My idea behind this is as follows:

1. Creating/Generating a new project happens only once, while upgrading happens dozens of times over the lifecycle of the software.
2. Applications (and also JHipster-generated apps) have a lot of dependencies. I rather don't want to manage those dependencies by hand (even with stuff like Dependabot).
3. It's important to be on the latest version for security, fixes, and to make dependencies work with modern frameworks (say JDK17).
4. Dependencies must work together well, and this must be tested.

I work mostly alone on my open source projects. It's my goal to work as much as I can on the 'business code/specific use cases and not be bothered too much about technologies and dependencies.

That's why I think it's so critical to start a project with the latest available dependencies when starting a new project, but also for using the latest versions when upgrading.

I let JHipster upgrade hundreds of dependencies for me. By this I am ensured that they work together and are safe to use, while I only need to focus on upgrading JHipster, instead of single dependencies.

Upgrading JHipster is btw not always that easy. Though I developed some scripts for it now. That's also why I discussed this topic at the beginning of the year on the discussion board of JHipster Lite:

https://github.com/jhipster/jhipster-lite/discussions/512

For now, both JH and JHL focus on generating new projects and not so much on upgrading projects made with older versions. That's fair, but I believe there is still a gap in the market here, just as significant as JHipster once filled for generating projects.

For me, the monthly releases could be just patch releases with only upgrades of minor dependencies (so nothing fancy like a major upgrade to Spring Framework 6/Spring Boot 3). Those major or even minor upgrades (with some added functionality and fixes) could be every three months (minor) or yearly (major).

I know JHipster is a community project, but I think that, for example the predictability of a release every six months with LTS releases is very nice.

I agreed that making upgrades seamless is not our strong suit. I've struggled many times when trying to upgrade 21-Points Health with npx jhipster upgrade. Sometimes, it works. Often, it does not. I think this is difficult to test because it can only be done after releases have happened. I wish I had a better answer. I suggested Raymond use some of his learnings to improve our upgrade sub-generator.

My responses are my opinions. I wanted to see what the JHipster project leads thought of my perspective, so I sent them a draft of this blog post. Pascal Grimaud responded with several excellent points.

> Possibly, but as far as I can tell, the same people aren't working on the same project. I believe that JHipster Lite was created because Pascal and others understand Java better than JavaScript, and they were lost in the JHipster codebase and wanted a Java version. JHL also emphasizes DDD and is not interested in CRUD, AFAICT.

Sorry Matt, but it's wrong. I didn't start JHLite because of technologies, Java or Javascript. It's the same; I don't care. I started JHLite to solve these problems I mentioned more than one year ago.

Problem #1: too many generated files.
Problem #2: hard to customize. Only a few users (less than 10) in the world maintain a blueprint. I know dozens of companies using JHipster (generator-jhipster). And none of them uses a blueprint.
Problem #3: too many options, too hard to maintain, so no new contributors for months. For an open source project, it's really sad.
Problem #4: complex templates.

A real story between a dev and me:
- dev: I found a bug in the SecurityConfiguration class. There is a missing line of code --> "xxxxx".
- me: Nice! We should apply it to our projects. Can you contribute back to generator-jhipster, too, please?
- dev: Good idea, it will be my first contribution to an open-source project! Let me try.
(hours later ...)
- dev: I don't understand. What's this f*cking SecurityConfiguration.java.ejs file?
- me: It's the template for managing security configuration for all existing options.
- dev: Should I apply it for JWT, too? for Session? Should I apply it for reactive too? Should I apply it for microservice?
- me: Yes, and you should test each config, please.
- dev: I don't care about these options, and as it's too complex, I gave up. As you're in the core team, you can do it yourself.
- me: OK, let's apply it only to our projects.

Problem #5: Too many projects, resulting in complex releases.
Problem #6: Yeoman, maintained only by Marcelo.

I started JHLite because:
- I don't use generator-jhipster anymore for my real projects, for real customers, because it doesn't fit.
- JHLite allows me to design my applications around BUSINESS instead of infrastructure.
- Modular approach, so it fits my needs.
- The quality of code, as each module is small, it's easy to have the best quality possible.

> In reality, I think many of the contributors have had difficulty figuring out how things work. However, we've always had JavaScript heroes to bail us out. In the beginning, Julien knew everything, so he could fix things quickly. Then, it was Deepu - who has admitted to me he rewrote the JHipster core a few times when he was super active. Now it's Marcelo, and I think he's doing a great job.

It's a big single point of failure! A big open source project like JHipster needs a community + contributors, not a hero.

Related to JHipster, I recently asked ChatGPT to write a poem about it.

I also asked it to compare JHipster versus JHipster Lite.

Wow, I'm impressed with both answers! 🤩

If you have additional questions about JHipster, hit me up on LinkedIn or ask your question on Stack Overflow with a jhipster tag.

Secure by Design Book Review

Matt Raible — Mon, 25 May 2020 20:11:22 -0600

I recently finished reading Secure by Design by Dan Bergh Johnsson, Daniel Deogun, and Daniel Sawano. I started reading it shortly after I received it as a gift from Dan Bergh Johnsson at Jfokus 2020.

I scored a signed copy of #SecureByDesign from @danbjson at #Jfokus. Excited to read the wisdom in this one! 🤗 #security pic.twitter.com/q0bxIvIwXF
— Matt Raible (@mraible) February 6, 2020

Secure by Design hooked me from the beginning. Chapter 1 dives right in and shows why design matters for security and how security shouldn't be an afterthought. The authors show how developers will have a difficult time grokking security if you make them remember security-related API calls. However, if you bake security into your design and codify your security practices, developers will be more secure by default.

I liked their Java example with domain primitives so much that I used it in my Security Patterns for Microservice Architectures blog post.

Chapter 1 ends with encouragement to view security as a concern to be met rather than a set of features. Design is the guiding principle for how a system is built and is applicable on all levels, from code to architecture. Well-known security threats should drive design decisions in security architectures.

One thing I appreciate about this book is they summarized each chapter's main points at the end. Writing reviews like this one are much easier with summaries. 👍

In Part 2, there's enough domain-driven design to make you knowledgeable, but not dangerous. In Chapter 4, they cover code constructs that promote security, like immutability and validation. Domain primitives are the smallest building blocks of a secure architecture. They can contain many checks above and beyond validation that will keep your developers cranking out secure code. The next two chapters discuss maintaining the integrity of the state and reducing state complexity.

Yeah, there's a lot to digest in this book. I read it over a few months.

Chapter 8 gets into leveraging your delivery pipeline for security and testing. I love that all the code examples in this section used JUnit 5 and were up-to-date with current Java testing practices. I felt like the book was just released last week!

Chapter 9 is an excellent tour of how exceptions can be used in your architecture to indicate failures. Or better yet, design for availability with resilience, responsiveness, and graceful failure handling. The availability of your data and system should be an important security goal and is part of the CIA acronym (confidentiality, integrity, and availability).

Chapter 10 gets into cloud-native thinking and the twelve-factor app. Once you have your apps running with twelve-factor concepts, you can adopt the three R's of enterprise security: Rotate, Repave, and Repair. In short, having an architecture where everything runs in the cloud allows you to take security to the next level, and:

Rotate secrets every few minutes or hours.
Repave servers and applications every few hours.
Repair vulnerable software as soon as possible (within a few hours), and a patch is available.

Part 3 is all about applying what you learned. How do you adopt domain primitives with legacy code? The authors suggest a few different options. Chapter 13 is all about microservices. I found it especially interesting to learn how logs can leak sensitive data and how logging data can be used after-the-fact to be a 2nd-level attack. The final chapter suggests guidelines for security in code reviews, challenging your design with penetration tests, and making security a source of inspiration.

Recommendation: A Strong Buy

I give Secure by Design 5 stars! ⭐️⭐️⭐️⭐️⭐️

I learned a lot of new information about designing secure systems and look forward to using this knowledge in my projects. Cheers to the book's authors: Dan, Daniel, and Daniel. I think you created an excellent security reference book that will help many developers and companies be more secure by design.

A Fantastically Fun February at Jfokus 2020 and the Rocky Mountain JUGs

Matt Raible — Sun, 15 Mar 2020 14:24:25 -0600

Jfokus is one of my favorite conferences in the world. It takes place in Stockholm, Sweden, during one of the coldest months of the year. As a native Montanan, I love the winter season and skiing. It was with great pleasure that I returned to Jfokus as a speaker this year, after skipping the last couple of years.

True story: the last time I was at Jfokus was 2017, and Okta had just acquired Stormpath. I negotiated my Okta employment terms in the Radisson Blu lobby!

I gave three talks this year: two on the main stage during Jfokus and one at Jforum Stockholm on Tuesday evening.

You can find my presentations below.

Jfokus also published recordings of my main-stage sessions on YouTube.

After Jfokus, the organizers planned a speaker's conference at Trysil Ski Area. There wasn't a ton of snow, but the groomers were fast, and they had a 45° double black!

I had my GoPro and shot some footage of the fun.

The beer tasting and dinner that evening at Kveik Restaurant & Brewpub was excellent!

Beer tasting at Kveik Restaurant & Brewpub in Trysil, Norway. ?? #jfokus #speakerconf pic.twitter.com/CR8t2fjmR6
— Matt Raible (@mraible) February 6, 2020

Friday was a gorgeous day on the slopes, and Saturday was the opposite.

Yesterday versus today. #whiteout #skiing #jfokus #speakerconf #day15 pic.twitter.com/L7ynGv0Umt
— Matt Raible (@mraible) February 8, 2020

I had a marvelous time at Jfokus 2020! Thanks to Mattias Karlsson and crew for a exquisite experience! 👌

For more photos see my Jfokus 2020 album

Rocky Mountain JUG Tour with Ray Tsang

I flew back to Denver on Sunday, February 9th. The next day, I woke up early for a Developer Ski Day at Eldora. Stout the Syncro was not a big supporter of the event.

Doh! Just when I thought my Syncro Westy was doing great, something breaks. Loud thump like I'd run over something, then a knocking while driving. I'm guessing it's a ball joint in the front.

Currently waiting for a tow from AAA.

Heckuva start to #DevSkiDay! #VanLife pic.twitter.com/2KMUZSTdtX
— Matt Raible (@mraible) February 10, 2020

Once I made it on the slopes, we had a ball with Christina, Ben, Robert, and Joel.

More photos →

On Tuesday, Ray and I prepared for our Rocky Mountain JUG Tour consisting of stops in Boulder, Denver, and Salt Lake City. I met him at a Google Boulder office and delighted in the VW decorations.

Our talk was titled Choose Your Own Adventure with JHipster and Kubernetes. We used JHipster to build and deploy whatever technologies the audience chose. We let them choose the database, the build tool, the JVM language, the web framework, and the architecture (monolith vs microservices). After we created the apps, I showed them running, and made them work with Okta. Ray took it from there and used JHipster's Kubernetes generator to add (or exclude) Istio and deploy everything to Google Cloud. When all worked on the first try at the Denver JUG, we were pretty pumped! 🙌

Interesting trends: we had a lot of enthusiasm for Grails in Colorado and all audiences chose microservices. You can skim through our presentation below.

On Friday, we hit the slopes for another developer ski day.

View this post on Instagram

?It's a #HappyFriday at @snowbird with @saturnism2 and @brettgpalmer! ?#DevSkiDay

A post shared by Matt Raible (@vwsforlife) on Feb 14, 2020 at 10:40am PST

Thanks to all the fine folks who joined our ski days and came to the JUG meetups! We loved the energy and community vibe from each location. ❤️😃

Ray and I had a Rocky Mountain adventure with JHipster, and you can too! From the comfort of your own home, you can install JHipster and choose your own adventure. Good luck, and please let us know if you have any questions.

My Journey to JHipster Conf 2019

Matt Raible — Wed, 3 Jul 2019 12:00:09 -0600

Last week was quite the whirlwind for me. On Monday, I released Ionic for JHipster 4.0, created a get started with JHipster 6 tutorial, and recorded a matching screencast. Within an hour of recording, I was on my way to the airport to fly to JHipster Conf.

I edited the screencast on my flight and published it to YouTube on my layover in Reykjavík. I was impressed that it uploaded just fine over airport Wi-Fi.

I took a long stroll that evening to Hébé Restaurant and had a delicious late night meal.

On Wednesday, I worked in the morning, then found a good lunch spot at Paname Brewing Company.

To celebrate the summer heat ?? in Paris, I searched for “breweries near me”, then walked to the one that looked the best. Worth it! ?? pic.twitter.com/RgU5fbVuME
— Matt Raible (@mraible) June 26, 2019

That evening, I journeyed to Julien Dubois's home and met his wonderful family. From there, we headed to the JHipster Conf speaker's dinner and experienced a marvelous evening. Thanks to Joe Kutner and Heroku for sponsoring!

The many faces of @java_hipster ?? #jhipster #jhipsterconf pic.twitter.com/hTPvOcjqOV
— Matt Raible (@mraible) June 27, 2019

Thursday was the big day of the conference. I woke up early, walked to La Défense in Paris, got lost a bit, and ended up arriving on time.

I was pumped to meet some local Okta folks and have them sponsor the event. I enjoyed quite a few talks throughout the day and learned how to add a CLI to your JHipster module.

I spoke about OAuth and OIDC just after lunch and published my slides to Speaker Deck. You can view my presentation below.

After the conference ended at 7pm, a bunch of folks attended a party at Ippon. They have an excellent location with a gorgeous views from their rooftop patio.

I agree with Cindy and Deepu's tweets about the conference. It was a fantastic experience!

I'm so grateful for this @jhipsterconf experience! You are a very special family! Thank you so much for bringing us together! ?? pic.twitter.com/yTkPQNlLJA
— Cindy Marin (@laslorma) June 28, 2019

Wow #jhipsterconf was such fun and such success. I hope everyone who attended enjoyed it. We had twice number of attendees from last year. I'm so glad I got to meet lot of core team IRL again.
So proud of the @java_hipster community. One of the few real #OSS community.
thread ?? pic.twitter.com/i5UoepeINo
— ?????????? ?? ???????????????????? (@deepu105) June 28, 2019

For more pictures, see my journey to JHipster Conf 2019 on Flickr.

A Beautiful Adventure to JBCNConf, Barcelona, and Boston

Matt Raible — Sat, 29 Jun 2019 09:33:15 -0600

I love it when school's out for summer. The feeling you have on the last day of school as a kid is like no other. It's a terrific feeling. The feeling of freedom. Our kids graduated from 10th and 8th grade at the end of May. We didn't give them much time to rejoice and whisked them off to Barcelona for a few days at JBCNConf and a bit of family vacation.

Oh my, it was so much fun! First of all, there's nothing like traveling to a foreign land, bringing some of your favorite people with you, and getting to experience it with old and new friends. We arrived on Sunday and experienced a wonderful evening at a conservatory for the JBCNConf speaker's dinner.

Monday was Memorial Day in the US, so we took advantage of our day off and booked a trip with Spanish Trails to explore Montserrat. Montserrat is a rocky mountain range in Catalonia, Spain. "Montserrat" translates to "saw mountain" in Catalan, owing to its jagged, sawtooth appearance.

On Tuesday morning, I took Abbie and Jack to JBCN4Kids and they learned all about game programming in Spanish. Their Spanish skills were tested, and there was an excellent keynote by Brian Goetz in the middle of it all.

That afternoon, Josh Long and I planned and practiced our Full Stack Reactive workshop. We had a nice lunch with my family and Mario that day too. Josh and I delivered our workshop on Wednesday morning.

If you'd like to see the slides @starbuxman and I never used during our Full Stack Reactive Workshop at @jbcnconf, we published them on @speakerdeck:https://t.co/LPyJvCxod6

Thanks to everyone who attended. We had a wonderful time! ??#reactive #java #springwebflux #reactjs
— Matt Raible (@mraible) May 29, 2019

The legendary @mraible and I got to close down @jbcnconf with a 2h workshop. Thanks to all those who joined! Couldn’t ask for a better co-presenter, audience, or way to spend the day. I love my life. pic.twitter.com/EbuqdblSsJ
— Josh Long (???, ???, ???? ????, ??? ????) (@starbuxman) May 29, 2019

Our family vacation in El Vendrell began shortly after that.

View this post on Instagram

@1trishphoto in her happy place 💕🥰

A post shared by Matt Raible (@vwsforlife) on May 30, 2019 at 7:00am PDT

We enjoyed the experience so much, Trish and I are thinking about spending even more time in Spain next year.

Goodbye, Barcelona! ?? ????

We had a splendid adventure touring your mountains, city, and beaches. ??@TrishPhoto is intrigued by the notion of visiting again next year.@spring_io and @jbcnconf 2020 with remote work in between? Sounds fun! ???? pic.twitter.com/340myZ1wai
— Matt Raible (@mraible) June 1, 2019

For more photos, see our album's on Flickr: my Barcelona, JBCNConf, and Boston 2019 or Trish's Barcelona 2019.

On the way home, we stopped in Boston and hung out with Trish's brother's family. Our niece, Morgan, graduated high school. We are very proud of her and had a blast celebrating the event.

We started off summer pretty well so far. We've been to Barcelona, Boston, and even had a weekend of whitewater rafting on Fathers Day weekend. Life is good in the Raible Hood! 😊

GIDS 2019: Adventures in India

Matt Raible — Thu, 2 May 2019 09:54:15 -0600

I had the pleasure of traveling to Bangalore, India last week for the 2019 edition of the Great International Developer Summit. GIDS is a conference that spans five days and has around 5000 developers each year. The conference charges on a per-day basis, and adds the attendees from each day to its total, so it's not huge, but it's pretty big with 1000+ developers each day.

A week before I left Denver, I solicited the advice of my good friend, Scott Davis. I asked him about the weather, the conference, and India in general. He advised me to wear lightweight clothing, no shorts when speaking and be wary of the wi-fi at the conference. He also mentioned the burgeoning microbrewery scene in "the Silicon Valley of India."

I've always been interested in traveling to India. My sister, Kalin, went there as part of her university studies 20 years ago. She studied Buddhism for four months on that journey and even got to meet the Dalai Lama. I thought it'd be fun to bring her along for my first trip to India. We rendezvoused in Seattle on the way, taking the picture below on Friday afternoon, April 19.

We had a long 14-hour flight from Seattle to Dubai. We flew Emirates and enjoyed the service, great seats (for economy), and wi-fi as we cruised over the North Pole. We had dinner at the Hard Rock Cafe in Dubai, then hopped on a four-hour flight to India. When we finally arrived at 3:00 am on Sunday, we were greeted with gifts in our room and a fresh slice of cake! Thanks to Dilip and Indu from Saltmarch for making us feel so welcome on our arrival.

We slept for a few hours after arriving, then met several of the GIDS speakers for a late breakfast. It was like a No Fluff reunion! If the names Venkat, Brian, Raju, Davis, Carducci, Stine, and Pratik sound familiar, you know what I mean. I quickly learned that Bangalore's name is actually Bengaluru, the British changed it to Bangalore during their rule.

After breakfast, Kalin and I took a car from the hotel and visited the Bangaluru Palace, followed by a stroll in the Lalbagh Botanical Gardens.

That evening, we joined some wonderful friends for dinner at Bangalore Brew Works. Bangalore Brew Works was my favorite restaurant on the trip. It was an open-air roof-top patio with cold, delicious beer, and spicy bites.

On Monday, it was time to go to work. I had four talks at GIDS; two on Monday. The conference started with Scott Davis and John Bruce having a fireside chat about the web. I'd just seen Sir Tim Berners Lee (John's co-founder at Inrupt) speak at Oktane 19, so I was delighted to hear from them both in the same month. Solid sounds like a very interesting concept, but I have not tried to build my own app with it, yet.

From there, it was kind of a blur. I'm not the kind of speaker that talks several times at a conference; I'm used to just one or two slots. I tend to do a lot of talks about Java and JavaScript. Since both have been innovating rapidly lately, I like to update my talks just before so they're up-to-date. For three days, I was updating presentations, practicing demos, and delivering talks. It was exhausting, but nothing like the other speakers. Several speakers had 10+ sessions and did a full-day workshop on Friday! 😳

My Presentations at GIDS

My first talk was "Front End Development for Back End Developers". I enjoy giving this talk because it doesn't have any live coding, but it packs a lot of information into 60 minutes. I published my slides on Speaker Deck and I believe it was recorded.

Monday afternoon, I spoke about JHipster and showed how to build a simple monolith from scratch. Since the wi-fi was spotty to non-existent, I had to do my demo with no internet connection. If you've used JHipster in the past, you know this can be a challenge. In the end, it seemed to go well, and I got lots of laughs as I progressively donned hipster clothing attire. You can find my presentation on Speaker Deck or view it below.

Monday evening, we gathered with conference friends at JetLag Bar and Grill and enjoyed the rooftop ambiance with the pulsating sound of house music.

Dinner at Jetlag Bar for the jetlagged peeps @CGuntur @mraible Kalin @scottdavis99 @MichaelCarducci Mrs. Carducci @BillyKorando @prpatel pic.twitter.com/hj6w7jEpmF
— Mary Grygleski (@mgrygles) April 22, 2019

On Tuesday afternoon, I spoke about bootiful development with Spring Boot and React. A couple of hours before the talk, I went to practice my demo and realized that I hadn't updated it in quite some time. I scrambled to update my demo script for the latest versions of Spring Boot, Create React App, and Okta. After updating and practicing, I prepared my laptop to do the demo without an internet connection.

When I started my demo, I planned on the internet failing, but I figured I'd show the audience first. In the midst of failure, one of the room hosts told me there was a backup wi-fi, got me on it, and away we went! You can see my slides on Speaker Deck or peruse them below.

Tuesday evening we gathered with folks from Oracle, Red Hat, IBM, and BNY Mellon at the Biere Club. They served excellent craft beer, yummy appetizers, and we laughed our way into the night. We particularly enjoyed our selfie at the end of the night.

Monday closing crew at #gids19! ???? pic.twitter.com/Axp5uRYqql
— Matt Raible (@mraible) April 22, 2019

Explanation: when my sister and I were strolling around the botanical gardens, we noticed a strange phenomenon we hadn't seen before: there were more men taking selfies than women. We also noticed that while the women were smiling, all the men were very serious in their photos. When in Rome!

I had my final talk about microservices with JHipster and OAuth on Wednesday morning. I'd just finished upgrading JHipster to use Spring Security 5.1 a couple of weeks prior, so I was eager to show it off. I used JHipster Registry and its Spring Cloud Config support to show how you can switch from Keycloak to Okta (or any IdP) by configuring just three Spring Security properties. Since your gateway and microservices are all configured to read from the registry on startup, you can configure your OIDC provider in a single location! You can download my presentation or view it below.

We retreated to our hotel on Wednesday afternoon, enjoyed massages gifted by Saltmarch, and I savored a cold beer at the patio bar.

This picture above is the last picture I took with my phone. When I was at the gym on Thursday morning, the screen started flickering on and off with hints of green. The screen was borked. I was hoping to use it for photos but decided it might be nice to have a break from having a phone.

Thursday afternoon, we toured the Bannerghatta National Park (aka the Bengaluru Zoo) with Ray Tsang. It was hot, the animals were exotic, and the safari tour was fast and furious. We had a fabulous time.

On Friday, Kalin and I headed to Mysuru (formerly Mysore) to see the sights. We hired a driver from our hotel for the three-hour drive. We visited a summer home of the rulers from the late 1700s, toured the Sri Chamundeshwari Temple, strolled through the Mysuru zoo, and took a quick tour around Mysore Palace. Unfortunately, I don't have any good pictures of our adventure.

You can find all the pictures in this post, and a few more, in my GIDS 2019 album on Flickr.

My first time speaking at GIDS was a lot of fun. Traveling to India with my sister was a special experience. Networking with developers, speakers, and old friends was fantastic. I told Kalin at one point, "the days are hard and rewarding, but the nights are spectacular." It's true. GIDS 2019 was a fantastic adventure with wonderful people.

The JHipster Mini-Book v5.0 Released!

Matt Raible — Wed, 14 Nov 2018 09:48:11 -0700

The JHipster Mini-Book v5.0 is now available as a free download from InfoQ. Get it while it's 🔥! You can also buy a print copy from Lulu. You can read more about this release on the JHipster Mini-Book blog.

The source code for the application developed in the book (21-Points Health) is available on GitHub.

Thanks to the InfoQ publishing team, Dennis Sharpe/Jeet Gajjar for tech editing, and Lawrence Nyveen for copy editing. And most of all, thank you Asciidoctor for making the publishing process so easy!

JHipster Conf 2018: Summer Solstice in Paris

Matt Raible — Thu, 28 Jun 2018 10:13:27 -0600

Last week, I journeyed to Paris with my son, Jack. It was his first time in Europe and I brought him along for good reason. I’d been invited to the first ever JHipster Conf, and I was eager to attend. We were both pretty excited when we left Denver last Monday.

Our adventure to Paris begins! #jhipsterconf

A post shared by Matt Raible (@vwsforlife) on Jun 18, 2018 at 4:01pm PDT

My Background with JHipster

I’ve been a part of the JHipster community for a few years now. I joined by accident, really. I was trying to market myself as an independent consultant by spouting my knowledge of Spring Boot and Angular with an InfoQ mini-book. Since JHipster leveraged both to jumpstart app development, it seemed like a perfect fit. I’ve been a long-time fan of app jumpstarts, having developed my own called AppFuse in days long gone.

Through the process of writing the mini-book, finding issues, and submitting pull requests, I eventually found myself to be a member of the JHipster development team. Through my relationship with JHipster, and it’s 3.0 release, I found myself intrigued my microservices and how to develop them with Spring Boot, Spring Cloud, all through the generation expertise of JHipster.

I’ve learned a ton by being part of the project and trying to figure out how all of its options work.

When I found myself with a full-time job at Stormpath, I did my best to create a Stormpath module for JHipster. When Okta acquired Stormpath, I added a similar module to my list of things I wanted to write.

When it came time to implement an Okta module, I discovered JHipster’s OAuth support only worked internally, not with an external OAuth provider, also known as an Identity Provider, or IdP. I mentioned to the JHipster team I thought we could do better and add support for external providers instead. They agreed, and I went to work.

In hindsight, it was a great decision and not terribly difficult to implement thanks to Spring Security, Keycloak, and Docker. We had a ton of help from the community along the way, and as of last October, JHipster added support for single sign-on with OIDC (tested with Keycloak and Okta).

JHipster 5.0: Spring Boot 2.0, Angular 6, and React

It’s been a fabulous adventure on the JHipster train and it’s still going strong. We just released version 5.0 with React and Spring Boot 2.0 support, there’s client generators for Ionic and React Native, and we just hosted a kick-ass conference about JHipster in Paris.

JHipster Conf 2018

The conference featured members of the core team, the well-dressed and fit Joe Kutner from Heroku, as well as Java celebrities like Ray Tsang and Josh Long. You can read about the festivities and presentations from JHipster's founder, Julien Dubois.

The conference was a little over 24 hours long, starting with a speaker’s dinner on Wednesday evening. Before attending, Jack and I spent the day strolling around Versailles. Versailles is a special place in my life since I proposed to my double rainbow there after Devoxx Belgium in 2011.

?? Versailles #working #jhipsterconf

A post shared by Matt Raible (@vwsforlife) on Jun 20, 2018 at 9:15am PDT

The conference kicked off with a keynote by the JHipster's co-leads: Julien and Deepu.

Full house at #JHipsterConf @java_hipster #paris pic.twitter.com/nnZ6JmlXrW
— Deepu K Sasidharan (@deepu105) June 21, 2018

JHipster Conf 2018 keynote from Julien Dubois

During my talk, I had Jack join me on stage for an intro, and tried to give him a taste of public speaking in front of hundreds.

After a fabulous day at #JHipsterConf and a fun rooftop party at @ippon_technologies , Jack and I enjoyed a romantic dinner and a bit of Fête de la Musique. ??

A post shared by Matt Raible (@vwsforlife) on Jun 21, 2018 at 2:44pm PDT

My talk went well, with some successful and some failed demos. Hopefully people got the point that it’s cool to store your users outside of JHipster so you can share them between apps. I also tried to show that OAuth and OIDC are excellent for securing APIs. You can download my presentation from Add JHipster to Your JHipster Apps with OIDC or view it below.

I created a tutorial of the app I showed in my talk and published it to the Okta developer blog: Build a Photo Gallery PWA with React, Spring Boot, and JHipster. If you like React and OAuth, you're gonna love this guide!

Jack and I had a day in Paris after the conference, so we made the most of it. We hit the Eiffel Tower, hiked the stairs, and marveled at the view. After, we waited in a long line for The Catacombs and walked among the dead.

I had a wonderful time this week in Paris and at @jhipsterconf. Many thanks to the @java_hipster developers, community, @juliendubois, @deepu105, and @ippontech for making it all possible! #JHipsterConf pic.twitter.com/61ZfRZxg8G
— Matt Raible (@mraible) June 23, 2018

Kudos to the JHipster Community!

What a trip! It’s so much fun to be a part of JHipster’s thriving open source community. It’s not just the project itself; it’s all the projects we build upon, from Java to TypeScript to Spring Boot to Spring Data to Spring Security to Angular to React to webpack to Bootstrap. It’s a conglomeration of all of my favorite tools and open source developers encompassed in several awesome projects!

Life as an open source developer is pretty fun. I encourage you to get involved in open source too! I started way back in the early 2000s with Struts and Ant, and it’s done wonders for my career.

Viva La Open Source!

SpringOne, The Rich Web Experience, and Being Home for the Holidays

Matt Raible — Fri, 22 Dec 2017 13:44:25 -0700

A few weeks ago, I had the pleasure of hitting two excellent conferences in one week: SpringOne and The Rich Web Experience. The primary reason I like both conferences so much is that there are so many familiar faces.

I had a gas hanging out with folks from Pivotal after I arrived on Monday night. On Tuesday, I thoroughly enjoyed the opening keynote. Seeing the unveiling of Spring Boot 2.0's most impressive feature was spectacular too!

Started as a dare, ended as a feature in @springboot 2.0! Animated Banners ?? #SpringOne pic.twitter.com/PqSDSWHMze
— Brian Clozel (@bclozel) December 5, 2017

I walked to the Okta office for some swag that afternoon, then proceeded to the Atomist happy hour. I talked with Rod Johnson about how Atomist might be able to help update our example apps and the Okta Developer blog. Since keeping our posts and examples up-to-date is a maintenance burden, I think Atomist could be a huge help.

After happy hour, a bunch of us joined Heroku for a delicious dinner and fun conversations.

Great night with @heroku friends @mraible @speakjava @starbuxman @afitnerd @Lspacewalker pic.twitter.com/JUVz0Ak2sH
— Joe Kutner (@codefinger) December 6, 2017

On Wednesday, I delivered my talk on Bootiful Development with Spring Boot and React. You can find my slides on Speaker Deck.

It was recorded and published to YouTube as well.

After my talk ended, I only had 70 minutes before my flight took off for Florida and the Rich Web Experience. Luckily, there was hardly any traffic and I found myself boarding with 23 minutes to spare.

The Rich Web Experience

At the Rich Web Experience, I had two back-to-back talks on Thursday morning. The first was on OAuth and is modeled off my What the Heck is OAuth blog post. I was surprised to have a packed room and appreciated the enthusiastic audience. You can find my slides on Speaker Deck or view them below.

I had an extra half-hour (compared to SpringOne) to deliver my Bootiful React talk, but I still managed to run out of time. The good news is it was largely because of audience interaction and questions. I feel like presentations are a lot more enjoyable when conversations happen during them. I published my slides afterward. The major difference between this deck and the one at SpringOne is I included Kent Dodds' free React courses on egghead.io.

I took a nice stroll along the Clearwater beaches that afternoon. I felt like a huge weight had been lifted off my shoulders since I was done speaking for the year.

On Friday, I flew back to Denver and spent the afternoon polishing all the READMEs in our developer example apps. We recently discovered that a lot of folks were trying our examples without reading our blog posts. As a developer, I know it's nice to clone a project, configure it, and run it. This should be much easier now. For example, if you look at the README for the okta-spring-boot-2-angular-5-example, you should be able to modify and run without reading its associated blog post.

Devoxx4Kids Denver

The next day, I helped organize a Devoxx4Kids Denver on building Fruit Ninja with Scratch. Melissa McKay was the class instructor and the kids had a blast. The workshop was hosted at Thrive Ballpark and they published a blog post about how Devoxx4Kids is Teaching Kids to Thrive.

#Devoxx4Kids Denver in full swing with @melissajmckay at @ThriveWorkplace. Fruit Ninja with @scratch! pic.twitter.com/ZqruHtVk0u
— Matt Raible (@mraible) December 9, 2017

Team Building and Denver JUG

The following week, I traveled to San Francisco to meet with my team and do some team building activities. I thouroughly enjoyed the stroll to work on Tuesday morning, and bowling that afternoon.

I feel very fortunate to have such a beautiful walk to the @okta SF office. #lifeatokta #embarcadero pic.twitter.com/NBaUmHtiFy
— Matt Raible (@mraible) December 12, 2017

I flew back Wednesday and made it just in time for the Denver JUG Holiday party. We had a pretty good turnout, announced some awards, voted on Venkat's talk in January, and gave out a few prizes. You can read more about the festivities on the Denver JUG blog.

When I drove home that night, I felt like George Bailey rushing home at the end of It's a Wonderful Life! The joy of being home without travel on the horizon is a wonderful feeling.

At the end of that week, I was able to find time to work on the Ionic Module for JHipster and release it.

Home for the Holidays

It's a great feeling to be home for the holidays. It was Trish's birthday weekend last weekend, so we watched her compete in a couple horse shows with Tucker. They sure do look good together, don't they?

Happy Birthday to my lovely wife, @TrishPhoto! She started the day at 5am so she could do one of her favorite things - competing with Tucker. ???? pic.twitter.com/XvLd81VRcz
— Matt Raible (@mraible) December 17, 2017

I'm done traveling for the year and I don't have any overnight travel scheduled until mid-February. My TripIt stats show I traveled quite a bit this year, and I'm looking forward to speaking at more JUGs and less conferences next year.

I spent 141 days on the road, but I'm grateful for getting to attend so many cool conferences in many exotic locations.

If you want to tinker with some code over the break, you can checkout my blog post on how to use Spring Security 5.0 with OIDC or my buddy Nate's Spread Serverless Holiday Cheer with Lambda and API Gateway.

Happy Holidays everyone! 😊

A Stressful, but Rewarding, Trip to Devoxx Belgium and Morocco

Matt Raible — Mon, 27 Nov 2017 08:37:50 -0700

One of my favorite conferences in the world is Devoxx Belgium. First of all, it tends to have one of the most enthusiastic audiences I've ever seen. Secondly, its organizers are super awesome and challenge you to give great talks. Third, it was the first conference I ever took my Trish to. In 2011, I took her a second time and proposed to her in Paris afterward.

This year, I traveled to Devoxx Belgium for the first time without Trish. It was stressful because I didn't prepare well beforehand. However, it was also gratifying because I was able to make everything work, even it all happened at the last minute. Furthermore, I did the majority of my talks with good friends, which is always a pleasant experience.

The purpose of this blog post is to document my experience this year, so I can look back and say WTF was I thinking?!

I left Denver on Monday (November 6) afternoon and flew to Brussels, Belgium. My flight landed in Brussels at 9 am and Josh and my (three hour) talk was at 1:30 pm. I made it in time, but it was one of the first times we didn’t have a lot of time to prepare face-to-face beforehand. I learned that getting t-shirts printed in the US to save $500 is a good idea, but having to take two suitcases to carry them all is a bad idea.

We did our usual talk and I used Okta's new Angular SDK instead of the Sign-In Widget to showcase authentication. Even though the crucial step I needed was contained in my notes, I failed. One simple line to add an HttpInterceptor and I missed it!

I think I followed up well with a tweet that showed how to fix it. But who knows how many people use Twitter. One things for sure, people tweet more at Devoxx Belgium than any other conference I’ve ever been too! In fact, the #Devoxx hashtag got hijacked by some porn sites and their tweets started showing up on the Twitter wall. ??

I tweeted about what I forgot to do after our talk.

Thanks to everyone who attended @starbuxman and my session on Cloud Native PWAs at @Devoxx!

Slides: https://t.co/3uyn4KUbm2

Source code: https://t.co/6deOtoHeeg

FWIW, I figured out why my @okta demo failed. I forgot to add the AuthInterceptor as a provider. Doh! #Devoxx pic.twitter.com/HxdYp6CetZ
— Matt Raible (@mraible) November 8, 2017

Josh and my talk was published on YouTube the very next day, which is awesome.

Tuesday night was the speaker’s reception, so I attended that and turned in around 10 pm. I worked on my next presentation (Angular vs. React) for a few hours after getting back to my hotel.

On Wednesday, I worked all day with my co-speaker (Deepu, co-lead of JHipster) on our Angular vs. React presentation. We worked for eight hours at the conference venue that day and parted ways around 6 pm.

On Wednesday night, I attended a dinner with Ray Tsang (Google Cloud Advocate). We were invited (along with Josh) to a dinner with JDriven. Josh couldn’t make it, but Ray and I attended and had a great time. I got home at 10 pm that night and worked on my next day’s presentation until 3 am.

Thursday, I worked with Deepu for a couple hours to polish and practice our presentation and we delivered it that afternoon. We also advertised the t-shirts we brought.

There were lots of tweets about our talk, but I think this from Daniel Bryant with our recommendations for Angular vs React was one of my favorites.

The results of the web framework smackdown are in...

via @mraible and @deepu105 at #Devoxx pic.twitter.com/MBYfZ2Fli4
— Daniel Bryant (@danielbryantuk) November 9, 2017

Our session went well, even thought it wasn’t super technical, and it was published to YouTube.

I also published our slides on Speaker Deck.

We had the JHipster BOF late that night (during the conference movie) and only had three people show up. With five committers there, we still had a great time, and it was fun to give Julien the Duke’s Choice Award trophy since he started the project.

@java_hipster team rocking @Devoxx @mraible @juliendubois @sendilkumarn #DukesChoiceAward pic.twitter.com/gaNpnJtBYR
— Deepu K Sasidharan (@deepu105) November 9, 2017

Duke might've had a little too much to drink during our BOF. :D

I thought our ratings (~4.2) for the two sessions were “good enough” to call the conference a success. Thanks to the conference organizers for delivering such an awesome experience once again.

Devoxx Morocco

I spent the weekend in Bruges and had a lovely time staying at an Airbnb and visiting some local breweries.

On Saturday night, I worked for several hours on the Ionic module for JHipster that I needed for my talk at Devoxx Morocco. That’s where the (self-inflicted) drama began. Here’s the timeline of events that I documented in my presentation after my talk:

After Devoxx Belgium, tried to finish Ionic module over the weekend.
Late night of hacking, couldn’t figure out why what worked last week didn’t work this week.
Discovered Ionic “super” starter was upgraded to Angular 5 in the last week.
Realized I needed to version the starter or write my own.
Tried to make OAuth work, because Okta.
Discovered OAuth wouldn’t work, because JHipster implementation uses cookies, and Cordova’s web view won’t work with cookies.
Sunday evening (my talk was on Wednesday morning): refactored everything into an Ionic starter.
Monday: finished starter, couldn’t get it to work in iOS emulator because CORS.
Found bugs about CORS doesn’t work over http. Spent hours trying to make it work over https. Couldn’t get a local certificate to be trusted, couldn’t deploy a JHipster app to the cloud (b/c of slow wifi). Even tried cloud-to-cloud, but ran into frontend-maven-plugin on Linux issues.
Monday afternoon: discovered real issue was that emulator runs on port 8080. Changed JHipster/Spring Boot’s port to 9000, and it worked!
Tuesday: delivered talk on Cloud Native PWAs with Josh Long. (https://twitter.com/mraible/status/930477708022337536)
Tuesday after dinner: started working on entity generator for Ionic.
Wednesday 4am: Got it working!
Wednesday 8-11:25am: wrote presentation.
Wednesday 11:30am: delivered talk, showed demo that worked!!

I published the slides from "Developing PWAs and Mobile Apps with Ionic, Angular, and JHipster" to Speaker Deck.

I also made a 5 minute video, because I recorded a lot of my development experience along the way.

Phew! It was an exhausting couple of weeks. I learned something I already knew - you should have your presentation finished before you leave for the conference, especially when traveling overseas!

Nevertheless, I had a great time. At Devoxx Belgium, it was announced that Josh and I both won Devoxx Champion awards. This award is given to speakers that attend all the Devoxx conferences in a year. Unfortunately, they never told either of us that we got it, so we missed it in the keynote. Luckily, it was recorded.

At Devoxx Morocco, they notified me five minutes before the keynote that “I should come” and that they had a surprise for me. I was in the midst of my last-minute scramble to get code working and write my presentation, but I went anyway. I’m glad I did because it was a very cool opening keynote and I was honored to receive a Devoxx Champion award.

I made sure to get my picture with Josh, and his girlfriend Tammie, after lunch.

There are two new Okta open source projects as part of my efforts, but they’ll require some polishing before they’re ready for general consumption. I hope to do that before the end of the year, but the end of January is probably more realistic. Below are links to their repos on GitHub:

For more photos from these events, see my album on Flickr. Devoxx Belgium posted their photos to a Devoxx2017 album, as well as albums for each day: day 1, day 2, day 3, day 4, and day 5. Devoxx Morocco posted all of their photos in three separate albums: day 1, day 2, and day 3.

I want to thank the organizers from Devoxx Belgium and Devoxx Morocco for accepting my talks and allow me to fulfill one of my goals for the year: becoming a Devoxx Champion. In 2018, I plan to slow down a bit and speak more in the US, concentrating on Java User Groups.

However, 2017 isn't over! I'll be speaking at SpringOne and The Rich Web Experience next week. We're also planning a Devoxx4Kids Denver meetup in December and a Denver JUG Holiday Party as well.

The JHipster Mini-Book v4.0 Now Available for Download!

Matt Raible — Fri, 22 Sep 2017 08:22:04 -0600

The JHipster Mini-Book v4.0 is now available as a free download from InfoQ. Get it while it's hot! You'll also be able to buy a print version in a week or two. You can read all about what’s changed since v2.0 on the JHipster Mini-Book blog.

The source code for the application developed in the book (21-Points Health) is available on GitHub.

Thanks to the InfoQ publishing team, Dennis Sharpe for tech editing, and Lawrence Nyveen for copy editing. And most of all, thank you Asciidoctor for making the publishing process so easy!

Devoxx Poland: A Huge Conference in a Beautiful City

Matt Raible — Tue, 27 Jun 2017 08:44:31 -0600

It's been a little over six years since I first ventured to Kraków, Poland. I have fond memories of that trip, mostly because Trish was with me and we explored lots of sites. Last month, I visited Kraków for GeeCON, but only stayed for one night.

Last week, I had the pleasure of visiting a third time for my first Devoxx Poland. I was excited to travel internationally again with my favorite travel shirt on. This caused a funny conversation with TSA just before my departure.

I arrived in Krakow on a beautiful day and took an Ubër to my hotel next to the venue. I took a stroll along the Vistula River to enjoy the sunshine.

I attended the conference happy hour that evening, then journeyed to a local restaurant for some delicious food and fun conversations. There's a chance one of those conversations inspires a speaking tour in South Africa next year.

On Thursday, I attended a couple sessions on application and microservices security, and delivered my talk on PWAs with Ionic, Angular, and Spring Boot. You can check out my presentation below or on Speaker Deck.

I was amazed at the sheer size of Devoxx Poland! Not only was the venue massive, but its 2500 attendees filled it up quickly. Thursday evening was the speaker's dinner, on a boat no less! It was a great location, with lots of familiar faces.

#DevoxxPL Speakers and Heroes pic.twitter.com/nat8xCS27F
— Matt Raible (@mraible) June 22, 2017

#DevoxxPL Speakers and Heroes, Part II pic.twitter.com/5wNpoFweeZ
— Matt Raible (@mraible) June 22, 2017

Friday, I spoke about What's New in JHipsterLand. My presentation can be viewed below or on Speaker Deck. You can download the PDF from Speaker Deck for clickable links.

Thanks #DevoxxPL - I had a blast! pic.twitter.com/Iho4HqTBYE
— Matt Raible (@mraible) June 23, 2017

In other news, I've been busy writing blog posts for the @OktaDev blog.

I also wrote an article for scotch.io titled "The Ultimate Guide to Progressive Web Applications."

For the next couple of weeks, I'll be on vacation in Montana. Then it's time for ÜberConf, vJUG (with Josh Long!), and Oktane17.

If I don't see you on the rivers in Montana or at an upcoming conference, I hope you have a great summer!

Speaking Adventures at J-Spring, Devoxx UK, GeeCON, and Spring I/O

Matt Raible — Wed, 24 May 2017 09:50:55 -0600

As a Developer Advocate at Okta, I'm expected to travel up to 25% per month to speak at conferences and meetups. This May was more like 50%! I had opportunities to contribute to a number of cool conferences in exotic cities that I was eager to accept.

My adventure began on Monday, May 8 when I flew to Amsterdam to speak at the J-Spring conference. It was the first time the NLJUG hosted this conference in several years. I marveled at the venue and especially liked the outdoor area it offered during breaks. The walk from/to the train station was pretty nice too.

I spoke about Microservices for the Masses with Spring Boot, JHipster, and JWT. Feedback I received mentioned it was a bit too fast and I crammed too much into the 50-minute time slot. I do tend to mention everything I know about topics when I speak, so I apologize for trying to cram too much in.

After J-Spring, I flew to London to speak at Devoxx UK. I arrived just in time to catch the speaker's dinner and had fun seeing and catching up with old friends from the conference circuit.

Thursday morning, I had an Angular workshop and did my microservices presentation in the afternoon. Friday, I had an early morning talk on Front End Development for Back End Developers. You can find all my presentations below.

I rushed straight from my last talk on Friday to the airport to catch a flight to Boston for the weekend. In Boston, we celebrated Trish's brother's 50th birthday, Mother's Day, and had a blast with friends and family.

The following Monday, I hopped on a plane to return to Europe with Krakow (for GeeCON) as my destination. Three flights later and I arrived in time to take a nice stroll around the city, enjoying the greenery.

At GeeCON, I spoke about how to build a progressive web app with Ionic, Angular, and Spring Boot. Half of my talk was live coding and I almost got all my demos working. Deploying to Cloud Foundry and my phone was the final step, and due to Xcode updating, that demo failed. I wrote a tutorial about Ionic for the Okta developer blog that has everything (and more!) that I showed in my demo.

I had to head straight to the airport after finishing my talk, this time heading for Spring I/O in Barcelona. Barcelona has always been on Trish's bucket list, so I easily talked her into joining me. At Spring I/O, I did a workshop on developing with Spring Boot and Angular, followed by my Front End Development for Back End Developers talk. There weren't that many talks on front-end development, so I felt privileged to be one of the few talking about UI development.

I also enjoyed Deepu's talk on JHipster and Sebastien's talk on Keycloak. It was the first time I'd met these great guys in person, so that was a lot of fun.

At @spring_io where @java_hipster's meet pic.twitter.com/I9OPErVWeF
— Deepu K Sasidharan (@deepu105) May 18, 2017

On Friday, Trish and I hit some of the sites in Barcelona and had a wonderful time. The weather was beautiful, the architecture was amazing, and the experience was awesome.

More photos on Flickr → European Speaking Tour - May 2017

Thanks to the organizers of each conference for allowing me to speak and for covering my travel expenses. My company doesn't pay for overseas conferences (yet!), but they do pay me while I'm there, so that's nice. To everyone that attended my sessions - thank you! I really appreciate the feedback and will do my best to improve future talks. If you have additional feedback, feel free to contact me.

In the meantime, keep an eye on the Okta developer blog. I've been writing a lot of articles lately and there's more to come in the pipeline! Here's a few that've been published in the last month.

Angular and Cloud Native PWAs at Devoxx France

Matt Raible — Mon, 10 Apr 2017 11:53:42 -0600

Devoxx France is one of my favorite conferences. As you might know from my post about Jfokus, I thrive on a sense of community and the memories created by conferences. Last week in Paris, I experienced a passionate community and created several memories, with many good people and friends.

I had two speaking events at the conference:

For the workshop, I intro'd Angular, had the class create an Angular application, then talked about testing Angular. In additional, I showed them a number of demos:

NOTE: Videos of my past performances about Angular can be found on YouTube:

Getting Started with Angular - Stormpath Webinar, January 2017
Testing Angular Applications - Jfokus, February 2017

Unfortunately, we ran out of time before folks could complete the testing Angular exercise, but it was a fun session nevertheless. I hope the students enjoyed it as much as I did!

I had a great time teaching these fun folks at my @angular workshop today!

Slides: https://t.co/pxqawNAaF2 #DevoxxFR #speakerselfie pic.twitter.com/6zeWGtnq0a
— Matt Raible (@mraible) April 5, 2017

Speaking about Cloud Native PWAs was a fantastic experience, mostly because of my good friend Josh Long. For those of you that have watched a @starbuxman talk, you know it's a great experience. Josh's well-timed jokes and stage presence is a source of envy for me. Sharing the stage with him was truly an honor.

We're about to kick off the part deux of our Cloud Native Apps series with @mraible @DevoxxFR pic.twitter.com/0GCSAiUgs4
— Josh Long (???, ???) (@starbuxman) April 6, 2017

We had a fine time creating a resilient beer craft service that was consumable by an Angular UI that works offline. The fancy name for this type of UI is a progressive web app, but I like to call it an installable webapp. It's a cool concept that leverages services workers to allow webapps to work offline. Besides service workers, all you need is TLS (HTTPS) and a bunch of icons (referenced in a linked manifest) to give an app installability. Unfortunately, service workers are not present in all browsers, so this works best for Firefox/Chrome users.

You can find the code we developed (from scratch!) in our talks on GitHub. The slide deck we used can be found on Speaker Deck.

Thanks to the organizers of Devoxx France for creating such a wonderful conference experience! I sure had a great time.

Thanks to @DevoxxFR and friends for a fantastic experience this week! Lots of fun memories created. ?? #DevoxxFR ?? pic.twitter.com/kCNZGVJyTB
— Matt Raible (@mraible) April 7, 2017

Update: Videos of Josh and my Cloud Native PWAs talks have been published to YouTube. Hope you enjoy!

Let the Okta and Devoxx Journeys Begin!

Matt Raible — Thu, 16 Mar 2017 11:43:59 -0600

It's been almost a month since Stormpath joined forces with Okta. My first day at Okta was on February 27, and I was only briefly in the San Francisco headquarters. I had to fly out at noon on my second day, so I hunkered down in the Okta Pub and cranked out a presentation for a talk with Micah Silverman at the Kansas City Spring User Group.

That's right, Okta has a pub in their SF HQ. When I first heard about this, I knew it'd be a good fit for me!

Now properly fortified, I finished the presentation and headed for the airport, where I rejoiced in my clothing choices for the day.

I love wearing this @goStormpath t-shirt when going through security at the airport. ?? pic.twitter.com/4oOGiaXEd9
— Matt Raible (@mraible) February 28, 2017

The whirlwind of ramping up at Okta hasn't died down yet. Last week, I figured out how to authenticate with Okta's API using Spring Boot and SAML. I also got an OAuth 2.0 example working. Then I moved onto Angular and got an example working with OpenID Connect (OIDC), Okta's Sign-In Widget, and the Okta Auth SDK. I was especially pumped when I got an Angular client working with OIDC and a Spring Boot + Spring Security backend. This week, I wrote up my findings as tutorials and recorded a couple screencasts to accompany them. These will likely show up as blogs posts on Okta Developer Blog over the next few weeks.

While the first couple of weeks at Okta has been exciting, I'm more excited about the upcoming Devoxx conferences I'll be speaking at.

Next week, Devoxx US will be happening for the first time! As a member of the program committee, I promise you this is going to be a great show! We had an incredible number of high quality submissions and it shows in the agenda. I'm especially looking forward to Janelle Klein's What is Identity? keynote. I'll be doing talks on JHipster, Asciidoctor, and how NOT to restore a VW Bus.

Speaking of the bus, Hefe sure looks good, doesn't he?

A post shared by Matt Raible (@vwsforlife) on Mar 15, 2017 at 7:24am PDT

After returning from Devoxx US, Trish and I are taking Abbie and Jack on the spring break trip of a lifetime. I've never been to Big Sky, so we're heading there for a week of skiing, frolicking, and playing in the snow. I might even go phoneless for the week to fully embrace the serenity that Montana provides.

I'm off to Devoxx France the following week. I'm really looking forward to this conference because my talks are all about Angular. I'll be doing a hands-on lab on getting started with Angular, as well as developing a PWA with Josh Long.

To make things even better while I'm on the road, I'm getting some work done on both VWs. We're getting Stout the Syncro painted and having a stereo installed in Hefe. With any luck, Stout 5.0 and Hefe 3.0 will be released in April, just in time for the car show season.

So yeah, life is pretty darn good right now. Let me know if you'll be in Tahoe, San Jose, Big Sky, or Paris when I'm there. I'd love to chat about authentication, open source technologies, VWs, or good beer.

A Jolly Good Time at Jfokus 2017

Matt Raible — Thu, 16 Feb 2017 17:21:23 -0700

I like speaking at conferences. I don't enjoy the stress of creating a new talk and delivering it for the first time, but I do enjoy delivering talks, and I love the feeling after. It's even better when the conference provides an atmosphere that creates lasting memories.

I've been to many conferences in my career. A conference with a sense of community provides one of my favorite experiences. Not just for the people that attend, but for the people that speak. I've been to several conferences that provide this experience and I'm happy to say I just attended one of my favorites: Jfokus 2017.

I flew from Denver to Stockholm last Monday and performed my first talk on Testing Angular Applications just a few hours after I arrived on Tuesday. Usually, I take a day or two to recover from jet lag, but this time I figured I could clutch up and make it work. Going to sleep on the plane at 6pm Denver time certainly helped and I think the talk went well. For the live coding part of the presentation, I used the second half of my Angular and Angular CLI tutorial. I posted my slides for this talk to SlideShare and Speaker Deck. You can also view them below.

Tuesday night, there was a conference party. I met many new people and put some names to faces with a vibrant community of conference attendees and speakers.

Late night #Jfokus party! pic.twitter.com/IqjczVXuP6
— Matt Raible (@mraible) February 7, 2017

I enjoyed Juergen Hoeller's talk about Spring 5 on Wednesday morning. There's a lot of innovation still happening within Spring and it was nice to get a sense of when releases will be happening.

Spring Framework 5.0 RC1 in April 2017, GA in May. @springboot 2.0 M1 in April too. Spring 5.1 with Servlet 4, Spring Boot 2.0 GA in Q4.
— Matt Raible (@mraible) February 8, 2017

I attended a talk on The Amazing Angular Router with Gerard Sans and then took a stroll around Stockholm in the crisp, cool sunshine.

I gave my talk on PWAs with Ionic 2, Angular, and Spring Boot on Wednesday afternoon. It was my first time doing the talk. I really enjoyed this talk because it inspired me to create Ionic pages for Stormpath to simplify the demo. Also, developing a mobile app with Ionic 2 has been on my technology bucket list for the last year. You can find my slides for this presentation on SlideShare and Speaker Deck. The app I wrote during the presentation is available on GitHub, as is the tutorial I used to create it.

Little did I know, the community aspect of Jfokus was just getting started. When I was invited to the post-Jfokus Speaker's Conference, I leapt at the opportunity. I didn't do it because I thought I'd learn a bunch of stuff, I did it because it offered skiing - one of my favorite activities.

It turned out to be an incredible experience. I knew some of the other speakers, but I certainly didn't know all of them. Sharing a room with a stranger caused him to become a friend. The views while skiing were magical. The coziness of the lodge where we stayed and the beauty of its atrium were mesmerizing.

I skied all three days, but I also had a blast sharing so many conversations with such a fun community of technology professionals. When I wasn't trying to catch up on email, Slack, and customer support tickets, we shared stories about how to best work with distributed development teams. Before enjoying the hot tub and roof-top sauna, we hacked games on Raspberry Pi's and make the zombie apocalypse possible with sensors and buttons.

On the bus ride back to Stockholm, I sat with Ray Tsang and figured out how to do another tech bucket list item: deploying a JHipster microservices architecture to Google Cloud. It wasn't easy with the bumpy road, but we took breaks when we started to feel sick. The bus had wi-fi, making it possible to upload fat Docker images to Docker Hub.

Hacking with @saturnism on the #Jfokus bus ride. Got a @kubernetesio cluster with @java_hipster microservices running on Google Cloud! ???? pic.twitter.com/wqest06HOu
— Matt Raible (@mraible) February 11, 2017

Before I left Sweden on Sunday, I walked around The Old Town in Stockholm and took a few pictures.

Upcoming Events: Devoxx4Kids Denver, Testing Angular 2, DevoxxUS CFP and VJUG24

Matt Raible — Fri, 12 Aug 2016 15:29:01 -0600

It's been awhile since I've posted anything on this here blog. That usually means one thing - I've been off having fun! That couldn't be more true this summer. The day after my last post, I began traveling and haven't stopped since. In fact, this weekend will be the first weekend I've been home since writing that post. Hawaii, Montana, Denver, Montana, Colorado Springs and Utah - it's been a fabulous summer. I'll write more about those adventures soon.

In the meantime, I wanted to mention some upcoming events you might be interested in:

September 10: Devoxx4Kids Denver has an upcoming workshop on Exploring JavaScript with the world famous Dr. Venkat Subramaniam. If you know Venkat, you know this is a session you shouldn't miss. Your kids will love it, you'll get a lot of good laughs and everyone is sure to have a good time. Make sure and RSVP soon so you get in before this baby fills up!
August 22: HTML5 Denver has a sessions on ES6 vs. Typescript and Testing Angular 2 Applications. The first session will be delivered by my good friend Geoffrey Filippi and I'll be performing the second act with the help of angular-cli.
September 1: One of my favorite conferences, Devoxx, is coming to the US! DevoxxUS recently announced that registration is open. Even more interesting is that the CFP begins September 1st. I'm biased because I'm on the program committee, but I'd love to see your ideas for great talks!
September 27: Our good friends from vJUG are hosting the first 24 hour Virtual Java Conference in the world! I'll be speaking about the Art of Angular in 2016 at 10pm EDT.
September: I'm looking for new clients. My current contracts end on August 31 and I'm searching for the next cool team to work with. My expertise: Java, JavaScript and I'm really good at CSS. This is a hard combination to find! LMK if you have a need.

I hope to see you at one of these events!

A Delightful Trip to Devoxx UK and GeekOut 2016

Matt Raible — Sun, 12 Jun 2016 11:13:17 -0600

I had the pleasure of traveling to London, England and Tallin, Estonia this past week. In London, I spoke at Devoxx UK. In Tallin, I spoke at GeekOut. I took my mom (or mum, if you prefer) and we explored the sights, enjoyed local cuisines and savored a few beverages. Our trip started with a direct flight from Denver to London. We arrived on Tuesday, June 7, around noon.

We were only in London for two nights, but it was enough time for us to savor excellent Indian food, fancy a walk through London, and order a bow tie. I forgot the bow tie for my JHipster outfit. Luckily, I found a good replacement and was able to order it for next-day delivery. I had to order it by 5pm and the site declined both my credit cards with time running out. I ended up using PayPal and got my order placed in the nick of time: 16:59:51.

The big news announced at Devoxx UK is that Devoxx is coming to the United States in 2017! I'm on the program committee for this conference, so I look forward to helping make it spectacular.

The first ever #DevoxxUS is happening March 21-23, 2017 in San Jose, CA! https://t.co/jtQe95LNOL
— Devoxx US (@devoxxus) June 8, 2016

I thought both my talks went well, but I did have some issues during my Angular 2 talk. I used Angular CLI to do the demo and IDEA kept indexing, which caused my live templates to fail. I later learned from an attendee (thanks!) that excluding the dist and tmp directories helps prevents this. You can find the source code for my demo on GitHub.

You can view my "Art of Angular in 2016" presentation on SlideShare, watch it on YouTube, or just click through it below.

I also did a presentation on JHipster, leveraging JDL Studio heavily. You can click here to see the JDL I used for my blog demo. A video of this session is on YouTube.

We closed out our visit to London with a fun speaker's dinner and an early morning flight to Helsinki, then Tallinn.

In Tallinn, we wandered through its Old Town, had some great meals and marveled at how late the sun set. We stopped in at the GeekOut conference's party on Thursday night. The ZeroTurnaround guys did a heckuva job planning this conference. I loved how both the party and the conference were in large, industrial-but-modern buildings with great sound systems.

My JHipster talk went well on Friday (slides here) and my mom and I celebrated at Rataskaevu 16 that evening. Then we shared laughs and learned how to play jackbox.tv at ZeroTurnaround's post-conference party.

Our last night was spent in Helsinki, a 20-minute flight from Tallinn. Since my grandparents are Finnish, my mom delighted in hearing words from her youth along the streets. We both took advantage and relaxed in our hotel's roof top saunas too. We indulged in a food/wine-paired dinner over three hours that evening.

Thanks to the organizers and good friends from Devoxx UK and GeekOut. We had a great time and are still smiling about all our new memories.

Update on June 20, 2016: Devoxx UK has posted a channel on YouTube with all of its sessions. You can view my Art of Angular talk or Get Hip with JHipster.

Moving AppFuse into the Attic

Matt Raible — Thu, 28 Apr 2016 15:40:16 -0600

In mid-February, I decided to stop working on AppFuse. My reason was simple: I was no longer getting any value from my contributions to the project. I sent a message to the developers mailing list the next day:

Hello everyone,

Last night, I started working on AppFuse 4.0, with the following features from the roadmap:

Remove XML wherever possible

Java 8

Spring Boot

Spring Data

JSR 303 (might require removing or developing client-side support)

As I started removing XML and integrating Spring Boot and Spring Data, it quickly became apparent that it’d be a lot of work to make all of these changes. My guess is it’d take over 100 hours of my time to do everything. This is time I’d be taking away from my family and personal time.

At the end of last year, I wanted to make AppFuse 4.0 happen because I thought it’d help me stay up-to-date with Java technologies and learn some things along the way. As I dug into the codebase last night, I realized it’d be more of a headache than a learning experience. It seems there would be little reward for all the work.

Because there’s little-to-no activity on the mailing list these days, it seems like it’s the right time to shutdown the project and dedicate my free time to other open source endeavors. As you might know, I’m a big fan of JHipster (http://jhipster.github.io/). It combines AngularJS and Spring Boot and has all the features that AppFuse has - but with a more modern technology stack.

If we had everything hosted on GitHub, I think it’d make sense to add a line to the README that says “This project is no longer maintained”. However, since there’s a lot hosted on appfuse.org (with Confluence), it might not be that easy. Maybe it’s possible to export everything from Confluence to static HTML pages and host them somewhere with the same URLs so there’s not a bunch of 404s from shutting down the project.

Thank you for your contributions over the years. AppFuse was pretty cool back in the day, but now there’s better solutions.

Cheers,

Matt

The good news is I've worked out a deal with Contegix to keep appfuse.org up and running for the next year. The demos, documentation and bug tracker will be available until April 30, 2017. Bamboo and FishEye will be discontinued in the next week since they're too memory intensive for a smaller server. I'd love to figure out a way to export all the documentation from Confluence to Asciidoctor so everything can be on GitHub for years to come. However, there's something to be said for just letting a project fade away rather than holding onto nostalgic artifacts.

On a related note, Java.net will be closing in a year from today. AppFuse started on SourceForge, but moved to appfuse.java.net shortly after. Today, the only thing left on java.net are AppFuse's mailing lists. I suppose it makes sense that both projects will cease to exist around the same time.

AppFuse's source code will remain on GitHub. I have no plans to delete it.

Thanks to everyone that used and contributed to AppFuse over the years. It was a pretty wild and crazy ride from 2003-2007!

Devoxx France 2016: Springtime in Paris

Matt Raible — Tue, 26 Apr 2016 07:13:18 -0600

I had the good fortune to visit Paris last week for Devoxx France. When traveling to conferences in exotic locations, I like to bring a travel partner. This time, I asked my daughter, Abbie, to join me. She gladly accepted. Springtime in Paris can be a beautiful event. The grass is green, the flowers are blooming and the sun's rays blanket the city.

We arrived in Paris on Tuesday, April 19 and quickly found our way to our hotel. Its location was ideal: across the street from Le Palais des Congrès de Paris convention center and mall. Since the conference was at the convention center, it made logistics for my talks very convenient. We grabbed a quick bite after settling in, then took a 15-minute stroll to the Arc de Triomphe.

That evening, we joined Ippon developers and friends at a special event for Java Hipsters. Their rooftop location had great views, cold "Java" beer and I met a lot of enthusiastic developers. I especially enjoyed talking with the original Java Hipster and founder of JHipster, Julien Dubois.

The sunset over Paris provided a splendid backdrop for the festivities.

On Wednesday, Abbie and I got up early and headed to Versailles. We toured Château de Versailles, the Gardens and Marie-Antoinette's estate. I'd never visited this area of Versailles and never realized what I was missing. We rented a boat and practiced rowing on the Grand Canal to get ready for rafting season.

That evening, we stopped by the Restaurant Le Sud for the speaker's dinner. It was fun seeing familiar faces and meeting new folks.

Thursday was my first talk, but we had the morning free to explore. We headed for the Eiffel Tower and rode its north elevator straight to the top. The views where spectacular and Abbie got goosebumps from the gentle sway.

I transformed from an old-fashioned, whiskey-drinking Java developer to a Java Hipster a few hours later. You can see the slides from my "Get Hip with JHipster" presentation below, or on SlideShare.

We wanted to see the Catacombs of Paris that night, and made it just minutes before it closed. Seeing the remains of millions of people's bones stacked on top of each other frightened Abbie more than standing on the glass floor in the Eiffel Tower. I experienced more heebie jeebies from the floor. We popped out of the Catacombs near the excellent Thai Paragon and stopped for a delicious meal. Abbie tried duck for the first time and loved it.

I had two talks on Friday, a quickie on how to write an InfoQ Mini-Book with Asciidoctor and a 45-minute session on The Art of Angular in 2016. I wrote the InfoQ Mini-Book presentation using Asciidoctor's Bespoke support and really enjoyed the experience. Thanks to Dan Allen for assembling this easy to use starter template! Dan was also a great help in getting the JHipster Book printed for the first time and I was pumped to have a copy with me to show off.

You can view the presentation online and checkout its repository on GitHub.

For my Angular presentation, I invited Abbie to kick things off, so she could experience what it's like to speak at a conference.

She did great and I followed her intro with my presentation on working with Angular 2. You can see my presentation below or check it out on SlideShare.

At the end of the conference, we attended the Les Cast Codeurs Podcast. It was all in French, but you could tell everyone was having a good time from the smiles and laughter in the audience. During the session, the Devoxx Crew surprised me with a Java Champion award. I was very surprised and humbled to receive this recognition. It was pretty cool having Abbie with me for such an honor.

Devoxx 2015: A Java Hipster Visits Belgium

Matt Raible — Tue, 17 Nov 2015 00:09:43 -0700

I've been excited to show people JHipster and what it can do ever since I started using it in September 2014. I've been using its core frameworks (AngularJS, Bootstrap and Spring Boot) for a few years and believe they do a great job to simplify web development. Especially for Java developers.

When my JHipster talk was accepted for Devoxx Belgium, I told Trish we were headed back to Belgium. She smiled from ear-to-ear. Belgium is one of our favorite countries to visit. In an effort to live healthier prior to Devoxx, I stopped drinking beer a month beforehand. I mentioned this to friends the week prior.

One month ago, I stopped drinking beer. I hoped it'd help me with www.21-points.com and weight loss. Unfortunately, it did not.

I told myself I'd start drinking beer again when 1) The Bus was finished or 2) Trish and I arrived in Belgium for Devoxx. Looks like #2 will win (we land on Tuesday).

We arrived in Brussels late Tuesday morning and hopped aboard a train to Antwerp. After arriving, we were hungry so we stopped at Bier Central for lunch. The mussels and beer were splendid.

We walked to our accommodations afterward, the Gernardin Guesthouse. We loved the small space, steep stairs and the nice use of space for the restroom in the upstairs closet. The breakfast was delightful too.

Wednesday afternoon we found ourselves strolling on a city walk around Antwerp. It was overcast, but not chilly and we had a fabulous lunch at Món after taking some pictures from the top of the MAS.

Wednesday evening, we journeyed to the Devoxx venue to deliver my presentation. The performance went well and I heard lots of positive feedback almost immediately. This is one of the things I love about Devoxx: the audience tweets like mad and feedback is immediate. I also like that the presentation displays are like developers monitors; huge!

Devoxx made an excellent move this year: they uploaded recordings of talks to the Devoxx 2015 channel on YouTube. Amazingly, they did it within hours for each talk! Because of this modern miracle, you can see Get Hip with JHipster on YouTube or watch it below.

SlideShare | Download PDF

Near the end of my presentation, I announced the source code for 21-Points Health is available on GitHub. I've had quite a few people ask for it as part of the JHipster Mini-Book and it seemed like the right thing to do. We celebrated that night with Josh Long and other new friends at Bier Central.

Thursday we visited Bruges and had a wonderful time strolling around Minnewater, marveling at the buildings near the main square and taking a clip-clop tour through town. We barely made it to the Bruges Beer Museum before it closed and had a delicious meal at Cambrinus.

More on Flickr → My Devoxx 2015 Album and Trish's Belgium November 2015 Album

Thanks to the Devoxx crew for a fun conference and great venue. Thanks to Belgium: for being so beautiful, for making savory chocolate, brewing delicious beer and for your wonderful people. And to the Java community: thanks for being so enthusiastic and fun to talk to. We love creating lasting memories with you! 🍻😊

Google's Mirror of Maven Central 25% Faster

Matt Raible — Tue, 10 Nov 2015 00:13:51 -0700

Last week, Takari announced that Google is Maven Central's New Best Friend. While writing a news article about this for InfoQ, I decided to run a small test to see the speed of the default Maven Central versus the new Google Cloud Storage instance. This micro benchmark didn't seem worthy of including in the article, but I think it's interesting to see the speed improvements I found.

I ran rm -rf ~/.m2/repository, then mvn install with the default repository configured. I ran the commands again with Google Cloud Storage. I found that the downloading of dependencies, compilation and running unit tests on AppFuse's web projects averaged 4 minutes, 30 seconds. With Google Cloud Storage, the same process averaged 3 minutes and 37 seconds. By my calculations, this means you speed up artifact resolution for your Maven projects by 25% by switching to Google. To do that, create a ~/.m2/settings.xml file with the following contents.

<settings>
  <mirrors>
    <mirror>
      <id>google-maven-central</id>
      <name>Google Maven Central</name>
      <url>https://maven-central.storage.googleapis.com</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
</settings>

Benchmark Details
My tests were run on a Mac Pro (late 2013) with a 3.5 GHz 6-Core Intel Xeon E5 processor and 32 GB of RAM. Bandwidth speeds during this test averaged 57 Mbps down, 6 Mbps up. Below are the timing numbers (in minutes) from my test:

Default: 4:33, 4:36, 4:32, 4:24, 4:09
Google: 5:13, 3:35, 2:15, 3:38, 3:39

Google had some wide variances in its results, with five minutes and two minutes. Because of this, I dropped the low and high numbers for each service before calculating the average. My math with raw numbers is below.

Default:
273, 276, 272, 264, 213 = 260, 4:20
276, 272, 264 = 270, 4:30

Google:
313, 215, 135, 218, 219 = 220, 3.66 = 3:40
215, 218, 219 = 3:37

Chen Eric commented on the InfoQ article to note that Chinese programmers are blocked from using Google.

Update: Jason Swank of Sonatype has done some more extensive benchmarking and found different results.

We found that average unprimed Google API (first mvn run) caching performed 30% slower than Maven Central. Primed Google API cache performance (second run) was 3% faster then Maven Central (second run). We also ran a number of cloud-based tests with similar results.

The JHipster Mini-Book: How We Did It and What's Next

Matt Raible — Tue, 3 Nov 2015 10:13:40 -0700

Last Friday, the JHipster Mini-Book was published on InfoQ. I wrote about this milestone on the book's blog. I'm pumped to see this release happen, and I'd like to give you a behind-the-scenes peak at how it went from idea to production.

The Idea
At the end of last year, I wrote down my goals for 2015:

21 Point Fitness App
JHipster Mini Book (InfoQ)
Finish Bus
New House
Good Blood Pressure

My reason for wanting to write a JHipster Mini-Book was simple: I knew AngularJS, Bootstrap and Spring Boot quite well. I'd used them on several projects and I really liked how JHipster married them all together. I often ran into people that used these technologies, but hadn't heard of JHipster. I was hoping to make more people aware of the project and market my development skills at the same time.

The first step to accomplishing a goal is writing it down. After writing it down and sharing with friends, I sent an email to Charles Humble, InfoQ's Head of Editorial, in early January. Charles directed me to InfoQ's internal mini-book guide and recommended I create an outline and talk to the project owners. It took me six weeks before I created an outline and sent it to Julien Dubois. We went back-and-forth on the outline for a while and finalized it around the beginning of April.

On April 8, I delivered a talk on JHipster at Denver's Java Users Group and announced I was writing the book.

The Development Process
Early on, I'd decided I wanted to write the book with AsciiDoc and build it with Asciidoctor. I did receive some slight push back (to use Google Docs) from InfoQ, but they were mostly supportive. Their biggest concern was getting it into a desktop publishing program and formatting it to fit their style. I have an email that says "this is going to be the most expensive book we’ve ever produced!".

I chose Asciidoctor because I wanted to run the book development and publishing process like an open source project. I also found its ability to import source code quite handy. I used the asciidoctor-gradle-examples project as a starting point, specifically the asciidoctor-to-all-example. I hadn't used Gradle on a project before, so I was motivated to learn it. Now that I think of it, I never even bothered to research how to use Asciidoctor with Maven.

I used JIRA in the cloud ($20/month) to create tasks, organize sprints and track my progress. I broke things down by chapter, starting with the UI components section, followed by Building an app, and API building blocks. I used the outline of the book to create my tasks. I gave myself a couple weeks for each chapter, but it ended up taking about a month each. I wrote the preface, introduction and everything else after the main content had been tech edited and was being copy edited.

I created a private repository on Bitbucket to host the book's source control in Git. The only reason I chose Bitbucket over GitHub was because Bitbucket offers free private repositories. It's a shame they have no plans to build a custom renderer for AsciiDoc.

I wrote the book using IntelliJ IDEA and used a combination of ./gradlew watch and Grunt with Browsersync to refresh my browser when changes were made.

Tech Editing
I sent my tech editors, Dennis Sharpe and Kile Niklawski, emails when I finished with a chapter. I gave them access to the book's repo, as well as the sample application's repo, and detailed how to access them. I made sure and documented how to build both projects in their README files. I asked Dennis and Kile to enter issues, or create branches and pull requests when they found problems. They entered a few issues on the first chapter, but responded via email after that. They didn't find many issues, so this process was good enough for me.

Copy Editing
Lawrence Nyveen copy-edited the book and was gracious enough to try my recommended process:

Checkout the source code of the book from Git.
Create a branch, make changes.
Publish the branch, create a pull request.
Have a conversation about the changes on the pull request, make more changes, merge pull request.

This process seemed to work very well and Laurie quickly learned how to work with Git. We both used AsciidocFX to edit and make changes. We used comments in the book's code to ask questions to each other. AsciidocFX worked quite well, though we did find we needed to add :imagesdir: images to chapter headers to get them to render images. Having problems with image rendering was not new, I had to create a symlink in the chapters directory to the images directory above it to get images to render in EPUB.

From the time Laurie started copy editing until he was finished was only a couple weeks.

Publishing
As I mentioned earlier, making the output look like InfoQ's mini-books was one of the biggest concerns with this book. InfoQ wanted to take the HTML (or PDF) version of the book, feed it into their desktop publishing program, and publish from there. I expressed my concerns in an email:

The JHipster project moves pretty fast, so it'll probably be a lot of work to pump out releases as quickly as they do. It's probably better to do a release per quarter with updated material. If you're going to reformat it every time we do a release, that could create a lot of work.

They agreed and mentioned the output from Asciidoctor was looking pretty good. They asked if I could make it match the standard InfoQ look and feel. I did some research, found out it might be possible, and went to work. It took me a week of research and a week of trial-and-error to produce the final product.

What's Next?
The good news is the first (1.0) version of the book is in production. I have not published 21-Points Health (the example application for the book) as an open source project, but I may in the future. For now, I hope to do my best to keep the book (and the app) up-to-date with JHipster releases. That may prove difficult, but we'll see.

One of the things I recommend in the book is to follow John Papa's Angular Style Guide. A recent pull request does this for JHipster. I think this is an excellent enhancement, but it'd also require me to rewrite many of the JavaScript sections of the book. It sounds like a daunting task, but at least it's a mini-book!

If you have any questions, comments or suggestions about writing with Asciidoctor or publishing with InfoQ, send them my way. My fastest responses will likely come from Twitter (@jhipster_book or @mraible). You can also leave a comment here, on jhipster-book.com, or post a question on Stack Overflow with the "jhipster-mini-book" tag.

P.S. If you live in Denver, there's a presentation on Asciidoctor by Tim Berglund and Cara Jo Miller tonight. I'll also be talking about JHipster at Devoxx next Wednesday.

SpringOne 2GX 2015: My Presentations on Comparing Hot JavaScript Frameworks and NoXML

Matt Raible — Sun, 20 Sep 2015 12:29:00 -0600

Last week, I had the pleasure of traveling to Washington, DC to speak at the annual SpringOne 2GX conference. I was pretty stressed for the last few weeks because I had to create two new presentations from scratch, and both had to be 90 minutes long. I was also hoping to finish the JHipster Book before the conference started. I was able to finish both presentations in the nick of time, but did not find the time to write the last chapter in the JHipster Book.

The first presentation was titled Comparing Hot JavaScript Frameworks: AngularJS, Ember.js and React.js. I started by revisiting the Comparing JVM Web Frameworks talk I did at vJUG last February. I explained how I think traditional web frameworks are no longer relevant in 2015, but I do believe server-side rendering is still very relevant. From there, I used Yevgeniy Brikman’s framework scorecard (from his Node.js vs. Play Framework presentation) to rank each framework by a number of different criteria. You can see the final results on slide 160. Since the scores were so close, I believe you could tweak some scores a bit (or add weights to the different criteria) and make any of the frameworks come out on top.

You can click through the presentation below, download it from my presentations page, or see it on SlideShare.

I started writing the second presentation a week before I had to deliver it. On Thursday, September 10th, I stayed up late, trying to figure out how to create a good presentation on NoXML and finish the last part of the JHipster Book. Then it came to me, I needed to parallelize and do them both at the same time. I decided to compare AppFuse (which is similar to a legacy Spring application with lots of XML) to JHipster (which hardly contains any XML).

I wrote a 10-page Google Doc on how I planned to do this, then went rafting and camping with my family for the weekend. I finished most of the presentation on Monday night, but then realized the presentation wouldn't be long enough to fill 90 minutes. So I hunkered down at midnight, created a new AppFuse application and removed a bunch of its XML. This took me until 3:30am, and I was able to accomplish the following tasks:

Spring XML to Java
Spring Security Configuration to Java
web.xml to WebApplicationInitializer
Spring MVC to Java
Migrated to Spring Boot
Maven to Groovy

I was pretty pumped when I completed my final goal: converting to Spring Boot and getting a test to pass. I made commits to an appfuse-noxml project on GitHub as I accomplished each step. You can see all the changes in the project's commit log. While I'd figured everything out, I still needed to complete the presentation. Luckily, I found time to do this the night before, the morning of, and in the final hour before I had to deliver the talk. You can imagine my relief when I was done delivering both talks.

You can click through the presentation below, download it from my presentations page, or view it on SlideShare.

While I didn't get to spend much time at the conference, I did have a lot of fun while I was there. I got to meet some new folks, reconnect with old friends, and enjoy beers and dinner with a smiling crew on Thursday night. The Broncos victory late that night was the icing on the cake.

Minecraft Modding at Denver's Devoxx4Kids

Matt Raible — Wed, 19 Aug 2015 08:41:52 -0600

Last weekend, Denver's Devoxx4Kids gathered at Tuliva to learn about Modding Minecraft. Several kids (ages 7-15) were introduced to programming Java by the founder of Devoxx4Kids USA, Arun Gupta, and his son, Aditya.

They used Java 8, Eclipse, Minecraft Forge and to show you how to create mods that could give you potatoes, skeleton cows, and even launch into different dimensions. The skeleton war was a big hit too. We had a record turnout at this event, and the space was fabulous. The live broadcast from vJUG went very smoothly and Tuliva's large screen and sound served us well. It was pretty sweet when we got shout-outs from the vJUG crew too!

Simon Maple wrote a great summary of the session that includes the video we watched, as well as an interview with Arun and Aditya. Take a look at Devoxx4Kid's Minecraft Modding Tutorial if you'd like to see what we learned.

We did run into a couple issues while trying to follow along. The first was that the virtual machines we were using wouldn't run the Minecraft client. The error we saw was:

org.lwjgl.LWJGLException: Pixel format not accelerated

We later learned from Arun that virtual machines were an issue and it's better to use Forge on a local machine. The second issue we ran into was when folks tried to build Forge from source, they got a 500 error when it tried to download http://export.mcpbot.bspk.rs/versions.json. We later learned that the firewall was blocking it.

Despite these issues, I believe the kids learned a lot by watching the vJUG broadcast. I spoke with some parents that got things working in the class, as well as a few that tried it when they got home. After the modding session, I showed the class how to create a Minecraft Server on AWS. I also did some research to see if you could automate the server creation. I quickly landed on Thomas Offermann's site and his tutorials:

Thomas created a couple GitHub projects: one to setup a Minecraft server on AWS, as well as a webapp that you can start/stop it with. I haven't tried either project yet, but I hope to soon.

Thanks to all the Denver kids and parents that joined us last weekend! The Tuliva facilities were spacious and comfortable. We owe them a big thanks for sponsoring Devoxx4Kids Denver! We hope to do another workshop this fall, possibly on Raspberry Pi.

How do I become a programmer?

Matt Raible — Thu, 13 Aug 2015 08:32:43 -0600

Yesterday, I received a message from a friend, asking about how to become a programmer. It's not the first time I've been asked this. In fact, this summer I've been asked by several friends how to get into the field. It seems that as people grow older, they see the lifestyle of working remotely and enjoying their job as an attractive thing to do. In yesterday's case, this friend is a mom that now has her days free because all her kids are in school. Here's what she wrote:

Now that my girls are both in school full day, I've been thinking about taking some programming classes. It's something I started to do while I was working at [ABC Company], but obviously didn't pursue once I quit to have kids. I'm thinking of getting my MIS in web development or specializing in designing apps if that's even a thing? Anyway, what languages would you recommend I concentrate on? JavaScript, Python? Lastly, is there a particular school you would recommend? I can't afford DU on my stay-at-home-mom salary, or even Regis which is where I started when I was getting tuition reimbursement. I was hoping I could do most of my education online while the kids are in school? Any advice or words of wisdom would be greatly appreciated!

Since this is a common question I see, I figured I'd publish my answers here, and get some advice from y'all too. Here's my response:

Python would definitely be good, as would JavaScript. JavaScript can be done on the client and server these days, so you could do that and be able to do front-end and backend development.

For programming specifically, I've heard these guys have a good JavaScript course: https://www.codecademy.com. Here's how to get started with Python in eight weeks: http://lifehacker.com/how-i-taught-myself-to-code-in-eight-weeks-511615189. And one of my favorites: http://programming-motherfucker.com/become.html.

I've taken a Scala course from Coursera, it was hard and intense, but I learned a lot. They have lots of courses and give you certifications you can put on your LinkedIn profile: https://www.coursera.org.

I've also recommended https://teamtreehouse.com to folks and https://www.khanacademy.org has always been good, even for kids.

Ultimately, the best way to learn to code is by doing. It's definitely good to study, learn and practice, but it'll probably won't sink in and become real knowledge until you're getting paid to do it. With the plethora of high-priced programmers out there, you can likely find a junior position, show a willingness to learn and come up to speed quickly. If you can couple that with a remote position, I think you'll really enjoy yourself.

Her response was interesting, as she thought she might need a CS degree to even get a programming job.

Coincidentally I looked over many of these coding sites yesterday but wasn't sure if I needed an accredited diploma. It sounds like it's more important that I just get some experience.

From my experience, a college degree matters, but not a CS degree. I told her people skills make programmers stand out and she's a witty person that certainly has those. What's your advice as a programmer? What would you tell people to do if they want to break into the field?

More importantly, if you're on the hiring side, what would it take for you to hire a 40-something person with no programming background? If they've been studying for six months and have really good people skills, would you hire them for a junior position?

Setting up a Minecraft Server in the Cloud

Matt Raible — Wed, 5 Aug 2015 15:03:00 -0600

My 10-year-old son, Jack, is a huge fan of Minecraft. If you let him, he'd play all day, skipping meals and having a blast. It's most fun to hear him playing with his sister or his best friend. I'm amazed it's captured his attention for so long; well over two years. Both my kids loved it when Scott Davis taught a Devoxx4Kids Denver class on Server-side Minecraft programming.

We haven't had any Devoxx4Kids Denver workshops this year, but that's about to change. First of all, I'm happy to announce we're working with the Rocky Mountain Oracle Users Group to have a Day of Family Coding Fun at Elitch Gardens this Friday. There will be a workshop on Raspberry Pi and I'll be doing a demonstration on how to setup a Minecraft Server in the cloud. Next weekend, we'll be doing a more in-depth Minecraft Workshop at Devoxx4Kids Denver. If you'd like to join us please RSVP. Since having your own Minecraft Server is a fun thing for kids, and useful for parents, I figured I'd document how to do it here.

First of all, let me say that I'm standing on the shoulders of giants. When I first setup a Minecraft server, I used Ben Garton's Setting up a free Minecraft server in the cloud - part 1 as well as part 2 and 3. I also found Aaron Bell's How to run a Minecraft server on Amazon EC2 to be quite useful.

Without further ado, here's you how to setup a Minecraft Server on Amazon Web Services (AWS) in 2015!

Step 1: Signup for AWS and Create an Instance

Navigate to http://aws.amazon.com/, and click "Sign In to the Console" using your Amazon account. If you don't have an AWS account, you'll need to create one and specify a payment method.
Click on EC2 in the top left corner, then Launch Instance on the following screen.
Select Amazon Linux.
Choose an Instance Type of t2.micro, then click Next: Configure Instance Details.
You don't need to configure anything on the next screen, so click Next: Add Storage. Storage settings don't need to be changed either, so click Next: Tag Instance.
On the Tag Instance screen, assign a name to your server. I chose "Minecraft Server". Click Next: Configure Security Group to continue.
This step is important because it opens a Minecraft port that allows players to connect. Create a new security group with name Minecraft and description Ports for Minecraft. Click Add Rule, specify Custom TCP Rule, Port Range 25565 and Source Anywhere. Note that you can also lock down your instance so only certain IPs can connect. Click Review and Launch to continue.
You'll be warned about allowing any IP address on the following screen. Click Launch to continue.
You'll be prompted to create a new keypair. I chose "minecraft" for my key pair name. Click Download to download your key pair.

I executed the following commands to move this key to a location on my hard drive and locked it down so the public can't view it.
```
mv ~/Downloads/minecraft.pem ~/.ssh/.
chmod 400 .ssh/minecraft.pem
```
Click Launch Instances to continue. You should see something like the following screen.
Click on the instance name and copy/paste the Public IP. You'll want to write down this IP address since you'll need it later, and you'll also want to send it to friends so they can join.

Execute the following command with this IP to connect to your server. Type yes when prompted to continue connecting.
```
ssh -i .ssh/minecraft.pem ec2-user@your-public-ip
```
You'll likely be told there's a number of updates to install; run sudo yum update to install them.

Step 2: Install a Minecraft Server

From your Linux prompt, type the following commands to create a folder and copy the latest version* of the Minecraft server into it.
```
mkdir MinecraftServer
cd MinecraftServer
wget https://s3.amazonaws.com/Minecraft.Download/versions/1.8.8/minecraft_server.1.8.8.jar
```
* Check http://www.minecraft.net/download to find out the latest version number and change the above command appropriately.
Create a symlink to the downloaded JAR so you can keep the same launch command, regardless of version.
```
ln -s minecraft_server.1.8.8.jar minecraft_server.jar
```
Launch your server using the following command:
```
sudo java -Xmx1G -Xms1G -jar minecraft_server.jar nogui
```
You should see ouput like the screenshot below, prompting you to agree to the EULA.
Edit eula.txt by running sudo vi eula.txt and changing "eula=false" to "eula=true". If you're unfamiliar with vi, the following instructions will help you edit this file after you've opened it.
- Type "/false" followed by [Return]
- Type "xxxxx" to delete "false"
- [Shift+A] to go to the end of the line
- Type "true"
- Hit [Esc], then type ":wq" to save the file
Run the sudo java command again (hitting up arrow twice will retrieve this command from your history). This time, the server should start, albeit with a few warnings about missing files.

Step 3: Connect to Your Server and Play!

This is the easiest step of all, and possibly one that your kids are familiar with.

Launch Minecraft. Make sure the profile uses the same version as your server. Copy the IP address of your server to your clipboard and click Play.
Click Multiplayer, followed by Add Server. Give it a name you'll remember and paste the IP address into the Server Address. Click Done, followed by Join Server.

Note: if you want to toggle fullscreen mode, you can do this with F11. If you don't have F11 on your keyboard, go to Options > Video Settings and click Fullscreen to toggle it.

Congratulations! You just setup a Minecraft server in the cloud. Now you can send the IP address to friends and invite them to play!

One of the issues that this setup has is that your server will shut down as soon as you logout of your SSH session. You can run the Minecraft server and leave it running using the following command.

nohup sudo java -Xmx1G -Xms1G -jar minecraft_server.jar nogui > minecraft.log 2>&1 &

This will keep everything running in the background, even after you logout. It also spits out a process id you can use to stop the server.

kill -9 processId

If you lose this number, you can find the process id by running ps aux | grep java. You can also shutdown all Java processes with sudo killall java.

If you have any tips or tricks for improving this tutorial, I'd love to hear about them in the comments.

Next Steps
When I first setup a Minecraft server on AWS earlier this year, I never bothered to shut it down. The result was it cost me around $15 the first month. From then on, I simply started it whenever my son asked me to, then shut it down when he went to bed.

Ben Garton has a good tutorial on how to setup a cron job to shutdown the instance at midnight. He also shows how to start the server using a Desktop shortcut on Windows. If you've done something similar for Mac/Linux, I'd love to hear about it. Allowing your kid to fire up their own Minecraft server on demand (and shutting it down automatically) seems to be the most economical way to run things.

Devoxx4Kids Denver Workshop Next Week
If you'd like to learn more about Minecraft, developing mods and setting up your own server, you should join us at the Devoxx4Kids Denver Meetup next week (Saturday, August 15th at 9:30am). We'll be tuning in live to Arun and Aditya Gupta's vJUG session on Getting Started with Minecraft Modding. In the second hour, I'll show how to setup your own server on AWS and configure it to have the mods we've developed while watching the vJUG session. Thanks to our venue sponsor Tuliva, you don't even need to bring a machine! They have computers available for the kids to use and a sweet location too. RSVP today!

Related: It seems you can also run a Minecraft server on Heroku using heroku-minecraft.

UberConf 2015: My Presentations on Apache Camel and Java Webapp Security

Matt Raible — Mon, 27 Jul 2015 08:08:48 -0600

Last week I had the pleasure of speaking at UberConf 2015. My first talk was on Developing, Testing and Scaling with Apache Camel. This presentation contained an intro to Apache Camel and a recap of my experience using it at a client last year. You can click through the presentation below, download it from my presentations page, or view it on SlideShare.

My second presentation was about implementing Java Web Application Security with Java EE, Spring Security and Apache Shiro. I updated this presentation to use Java EE 7 and Jersey, as well as Spring Boot. I used Spring Boot to manage dependencies in all three projects, then showed the slick out-of-the-box security Spring Boot has (when you include the Spring Security on the classpath). For Apache Shiro, I configured its filter and required dependencies using Spring's JavaConfig. You can click through my security presentation below, download it from my presentations page, or view it on SlideShare.

One thing that didn't make it into the presentation was the super-helpful pull request from Rob Winch, Spring Security Lead. He showed me how you can use basic and form-based authentication in the same app, as well how to write tests with MockMvc and Spring Security's Testing support.

The next time I do this presentation (at the Rich Web Experience), I'd like to see if it's possible to use all-Java to configure the Java EE 7 example. I used web.xml in this example and the Servlet 3.0 Security Annotations might offer enough to get rid of it.

All the demos I did during the security presentation can be seen in my java-webapp-security-examples project on GitHub. There's branches for where I started (javaee-start, springsecurity-start and apacheshiro-start) as well as "complete" branches for where I finished. The complete examples should also be in-sync with the master branch.

If you have any questions about either presentation, please let me know.

Grails + Angular vs. JHipster

Matt Raible — Tue, 14 Jul 2015 08:02:01 -0600

I recently received an email from a long time follower of my comparing web frameworks research and presentations. He asked some interesting questions:

I am starting on a new venture to build a direct to consumer web application. I am planning to leverage Cloud services to build my CI/CD pipeline. I am very strong with Java Backend/middleware and learning Javascript Front-end frameworks. I love Spring and SOFEA. Having said that, I am wondering if I should use Grails + Angular or JHipster? My primary concern with JHipster is there is hardly any ‘community', there is Julien and whatever he says/thinks goes! Can you give me some pointers?

I imagine there's other JVM developers with similar questions, so I figured I'd publish my response for all to see.

JHipster may have a smaller community than Grails, but remember that it's built on Spring Boot and AngularJS. Both have huge communities. In fact, Grails 3 is built on Spring Boot, just like JHipster.

Even though JHipster generates your code in Java, there's nothing preventing you from writing your code in Groovy or Scala. I dig JHipster, but I've also worked with AngularJS and Spring Boot for a couple years. The fact that someone put these technologies together and makes it easy to work with them is awesome.

I like JHipster so much, I decided to write a book on it. I hope to finish it in the next couple months and have it published in the fall. It'll be a free download from InfoQ. Learn more at http://www.jhipster-book.com.

Yes, I'm probably a bit biased since I'm writing a JHipster book. However, it's been easy for me to introduce and use Spring Boot at my last few clients. They were already using Spring, so the transition to using a Spring simplifier was a no-brainer. I haven't had as much luck getting clients to adopt Grails, even though I've suggested it. That could change now that it's based on Spring Boot.

What's your experience? Would you recommend Grails + Angular over JHipster? If so, why?

Getting Hip with JHipster at Denver's Java User Group

Matt Raible — Thu, 9 Apr 2015 08:31:54 -0600

Last night, I had the pleasure of speaking at Denver's Java User Group Meetup about JHipster. I've been a big fan of JHipster ever since I started using it last fall. I developed a quick prototype for a client and wrote about solving some issues I had with it on OS X. I like the project because it encapsulates the primary open source tools I've been using for the last couple of years: Spring Boot, AngularJS and Bootstrap. I also wrote about its 2.0 release on InfoQ in January.

To add some humor to my talk, I showed up as a well-dressed Java Developer. Like a mature gentleman might do, I started the evening with a glass of scotch (Glenlivet 12). Throughout the talk I became more hip and adjusted my attire, and beverage, accordingly. As you might expect, my demos had failures. The initial project creation stalled during Bower's download all JavaScript dependencies. Luckily, I had a backup and was able to proceed. Towards the end, when I tried to deploy to Heroku, I was presented with a lovely message that "Heroku toolbelt updating, please try again later". I guess auto-updating has its downsides.

After finishing the demo, I cracked open a cold PBR to ease my frustration.

I did two live coding sessions during this presentation; standing on the shoulders of giants to do so. I modeled Josh Long's Getting Started with Spring Boot to create a quick introduction to Spring Boot. IntelliJ IDEA 14.1 has a nice way to create Spring Boot projects, so that came in handy. For the JHipster portion, I created a blogging app and used relationships and business logic similar to what Julien Dubois did in his JHipster for Spring Boot Webinar. Watching Josh and Julien's demos will give you a similar experience to what DJUG attendees experienced last night, without the download/deployment failures.

You can click through my presentation below, download it from my presentations page, or view it on SlideShare.

You might notice my announcement on slide #32 that I've signed up to write a book on JHipster.

I haven't started writing the book yet, but I have been talking with InfoQ and other folks about it for several months. I plan to use Asciidoctor and Gradle as my authoring tools. If you have experience writing a book with these tools, I'd love to hear about it. If you've developed an application with JHipster and have some experience in the trenches, I'd love to hear your stories too.

As I told DJUG last night, I plan to be done with the book in a few months. However, if you've been a reader of this blog, you'll know I've been planning to be done with my '66 VW Bus in just a few more months for quite some time, so that phrase has an interesting meaning for me.

How To Setup Your Own Software Development Company, 6 Years Later

Matt Raible — Mon, 2 Mar 2015 09:26:01 -0700

Just over six years ago, I wrote a popular post titled How To Setup Your Own Software Development Company. I'd just left LinkedIn a few months earlier and was enjoying consulting life again, working with a group of friends at Evite. In the article, I wrote about how I liked consulting because it forces you to keep your skills up-to-date and it pays a lot better. I also talked about the type of legal entity you should form (I have an S Corp), what business insurance you should buy, what I had for health insurance and how I automated payroll and tax payments.

I recently received an email from a reader, asking me if I had any updated thoughts.

It's been nearly six years since you wrote the article about starting your own business ... and thanks, by the way.

I am starting my venture into independent contract work as a software engineer (Java technology) in California and most likely will setup an S corp entity.

Seeing that you wrote this six years ago and things have considerably changed in the U.S. (economy, health care, etc.), I was wondering if you had some updated thoughts to share, perhaps some learned lessons even.

And also, I have questions about business insurance: what type of insurance should I opt for? Is there really an umbrella insurance out there? Or does each (or many) clients out there dictate the insurance you need?

Yes, a lot has changed in the last six years. The economy has improved and health care costs have risen. Through this time, I've been able to continue to operate as an independent software developer and keep the contracts flowing. Personally, the biggest changes in my life have been outside of work. I met an exceptional woman, traveled to conferences all around the world with her, got married, traveled some more, then bought a VW Westfalia so we could have lots of fun traveling in our own backyard. All the while, I've worked for some great clients. I built a team of hot shots at Time Warner Cable (many of them still work there), I skied the awesome powder of Utah while working at Overstock and I enjoyed a long-term contract at Oracle. After Oracle, I got into the healthcare industry and I've been working in it ever since.

In fact, I just finished working for a healthcare company last week and I'm on the hunt for my next gig in April. Check out my LinkedIn profile if you'd like to see my résumé.

I've learned quite a few lessons over the last several years. As an independent developer, the biggest thing I've learned is marketing is key. I've always known this, but I've been reminded of its importance a few times. When I worked at Taleo (after Overstock), I was on a 3-month contract that turned into a 9-month contract that got a 1-year extension when Oracle bought them. The work was challenging, but the application was outdated. Getting them to adopt new technologies like Bootstrap and AngularJS was difficult. When Oracle took over, they offered me a 1-year contract at a great rate. I accepted, never thinking it would be difficult to get paid from someone like Oracle. It took them over three months to pay my first invoice and it took me another three months to get payments flowing regularly. I felt like I was trapped. I felt like I could quit, but that wouldn't speed up the process of getting my invoices paid. From this experience, I'm hesitant to start with any contract that's longer than three months.

During my time at Oracle, I didn't blog as much as I had previously (because the day-to-day work wasn't that exciting), but I did still speak at conferences. Last year, I took the year off from speaking at conferences altogether. Speaking is an excellent marketing tool. Because of my lack of speaking, I saw a downturn in contract opportunities in Q4 last year.

As far as health insurance is concerned, I continued to have a disaster prevention plan, with a $5K per year deductible. I paid around $300/month for this, and rarely used it. By riding my bike to my office in downtown Denver, and skiing a bunch in the winter, I felt like I was pretty healthy. After I stopped eating sugar last fall, I became much healthier. So much healthier that I've stopped taking high blood pressure medication. Today, I don't pay for health insurance. Trish went back to IT Security Sales in November and she was able to get me on her company's plan for $100 cheaper than what I was paying. I didn't have dental insurance for the last five years and I did have to shell out $5K for a tooth implant at one point.

For business insurance, I have the Business Owner's Policy from The Hartford. I pay around $600/year and I've gotten that back when I've had laptops stolen or accidentally killed my iPhone. I've got automated backups going all the time, so I haven't lost any data in several years. This insurance policy and its liability coverage has been "good enough" for all my clients, including the big ones.

I think the biggest lesson I've learned in the last several years is that the best way to be rich is to be rich in time. I've always dreamed of making $500/hour and working 20 hours per week. While $500/hour sounds crazy, you know there's consultants out there that are making that kinda cash. They're probably not in software, maybe they're political consultants, or former professional athletes, but those consulting rates do exist. In software, there's certainly companies that bill those kinda rates. My rates for the last several years haven't been that good, but they've been pretty awesome.

Earlier this year, I had the opportunity to work 20 hours per week instead of 40. It was one of the greatest work-life experiences I've had to date. I was still able to pay all my bills, and I had time during each-and-every-day to do something fun. When working 40 hours per week, exercising and cooking dinner were somewhat of a chore. When I flipped to working less, work became the chore and exercise and cooking became the fun parts of my day. I read somewhere recently that if Americans valued health over wealth, we'd be a lot better off. I felt like I did this when working less and that I was rich in time.

Related to feeling better over making more, I've started to target employment opportunities that offer a good team to work with. For the last year, most of my contracts have been with remote clients, where they haven't required me to travel onsite. While this sounds great in theory, I do miss the comradery that exists when working with a team. Working with someone over a Skype/HipChat call is nothing like sitting next to each other and cracking jokes while writing code. Don't get me wrong, I love remote work, but I do think it's important to be onsite and collaborating face-to-face at least once per month.

To those individuals looking to start their own Solopreneurship, I hope this advice helps. It's been a great experience for me.

AppFuse 3.5 Released!

Matt Raible — Fri, 20 Feb 2015 09:08:53 -0700

The AppFuse Team is pleased to announce the release of AppFuse 3.5. This release contains a number of improvements.

XML reduced by 8x in projects generated with AppFuse
CRUD generation support for Wicket, as well as AppFuse Light archetypes (Spring Security, Spring FreeMarker and Stripes)
Upgraded Tapestry to 5.4
Integrated Spring IO Platform for dependency management
Refactored unit tests to use JUnit 4
Renamed maven-warpath-plugin to warpath-maven-plugin
Upgraded to jWebUnit 3 for AppFuse Light integration tests
Updated all AppFuse Light modules to be up-to-date

For more details on specific changes see the release notes.

What is AppFuse?
AppFuse is a full-stack framework for building web applications on the JVM. It was originally developed to eliminate the ramp-up time when building new web applications. Over the years, it has matured into a very testable and secure system for creating Java-based webapps.

Demos for this release can be viewed at http://demo.appfuse.org. Please see the QuickStart Guide to get started with this release.

If you have questions about AppFuse, please read the FAQ or join the user mailing list. If you find any issues, please report them on the users mailing list. You can also post them to Stack Overflow with the "appfuse" tag.

Thanks to everyone for their help contributing patches, writing documentation and participating on the mailing lists.

We greatly appreciate the help from our sponsors, particularly Atlassian, Contegix, and JetBrains. Atlassian and Contegix are especially awesome: Atlassian has donated licenses to all its products and Contegix has donated an entire server to the AppFuse project.

Converting an Application to JHipster

Matt Raible — Thu, 12 Feb 2015 09:28:59 -0700

I've been intrigued by JHipster ever since I first tried it last September. I'd worked with AngularJS and Spring Boot quite a bit, and I liked the idea that someone had combined them, adding some nifty features along the way. When I spoke about AngularJS earlier this month, I included a few slides on JHipster near the end of the presentation.

This week, I received an email from someone who attended that presentation.

Hey Matt,
We met a few weeks back when you presented at DOSUG. You were talking about JHipster which I had been eyeing for a few months and wanted your quick .02 cents.

I have built a pretty heavy application over the last 6 months that is using mostly the same tech as JHipster.

Java

Spring

JPA

AngularJS

Compass

Grunt

It's ridiculously close for most of the tech stack. So, I was debating rolling it over into a JHipster app to make it a more familiar stack for folks. My concern is that it I will spend months trying to shoehorn it in for not much ROI. Any thoughts on going down this path? What are the biggest issues you've seen in using JHipster? It seems pretty straightforward except for the entity generators. I'm concerned they are totally different than what I am using.

The main difference in what I'm doing compared to JHipster is my almost complete use of groovy instead of old school Java in the app. I would have to be forced into going back to regular java beans... Thoughts?

I replied with the following advice:

JHipster is great for starting a project, but I don't know that it buys you much value after the first few months. I would stick with your current setup and consider JHipster for your next project. I've only prototyped with it, I haven't created any client apps or put anything in production. I have with Spring Boot and AngularJS though, so I like that JHipster combines them for me.

JHipster doesn't generate Scala or Groovy code, but you could still use them in a project as long as you had Maven/Gradle configured properly.

You might try generating a new app with JHipster and examine how they're doing this. At the very least, it can be a good learning tool, even if you're not using it directly.

Java Hipsters: Do you agree with this advice? Have you tried migrating an existing app to JHipster? Are any of you using Scala or Groovy in your JHipster projects?

Integrating Node.js, Ruby and Spring with Okta's SAML Support

Matt Raible — Thu, 8 Jan 2015 11:43:47 -0700

Security has always piqued my interest, ever since I first developed AppFuse and figured out how to make J2EE security work back in 2004. I hacked AppFuse to have Remember Me functionality, then moved onto Acegi/Spring Security. Spring Security had the features I needed, even if it did require almost 100 lines of XML to configure it. These days, it's much better and its JavaConfig - combined with Spring Boot - is pretty slick.

That was the first part of my security life. The second phase began the night I met Trish, and learned she sold security products. She knew of OWASP and their top 10 rules. It was Trish that inspired me to write my Java Web Application Security presentation. I really enjoyed writing that presentation, comparing Apache Shiro, Spring Security and Java EE's security frameworks. I followed up the first time I presented it with a number of blog posts and screencasts. Hmmmm, maybe I should update the presentation/screencasts to use Java configuration only (#NoXML) and submit it to a couple conferences this year? I digress.

I had to do a security-related spike over the last couple weeks. I was trying to get SAML authentication working with Okta and my client's Active Directory server. Luckily, someone setup the AD integration so all I had to do was try a few different languages/frameworks. I searched and found ThoughtWorks' okta-samples, which includes examples using Node.js and Sinatra (Ruby + JRuby). I also found a Spring SAML example that includes one of my favorite things in JavaLand: Java-based configuration.

I'm happy to report I was able to get all of these applications working with my client's Okta setup. This article will tell you how I did it. For each application, I created a new application on Okta using its "Template SAML 2.0 Application" and added myself in the application's "People" tab. Each section below contains the configuration I used for Okta. The instructions below assume you're similar to me, a developer that has Java 8, Node and Ruby installed, but none of the specific frameworks. As I write this, I have everything working on my Mac with Yosemite, but I wrote the instructions below using one of my old laptops, fresh after a Yosemite upgrade.

The first thing I did was checkout ThoughtWorks samples.

git clone https://github.com/ThoughtWorksInc/okta-samples.git

Node.js

I started by getting the Node.js sample working. For Okta's configuration, I used:

Setting	Value
Application label	Okta Node.js Example
Force Authentication	false
Post Back URL	http://localhost:3000/login/callback
Name ID Format	EmailAddress
Recipient	http://localhost:3000/
Audience Restriction	http://localhost:3000/
authnContextClassRef	PasswordProtectedTransport
Response	Signed
Assertion	Signed
Request	Compressed
Destination	http://localhost:3000/login/callback
Attribute Statements	email\|${user.email},firstName\|${user.firstName}

The Node.js sample uses express, as well as passport and passport-saml. The passport packages are used to handle the SAML authentication and connect is used to compress the requests from your local server.

The only thing I needed to do to make the Node.js app work was to paste the X509 cert string and target URL into its config.json from the Okta app. In Okta's Admin interface, I clicked on the "Sign On" tab and clicked its "View Setup Instructions" button. I copied the "Redirect Login URL" value and copied it into config.json's entryPoint value. I then downloaded the certificate and opened it in vi. I ran the following two commands to remove ^M and line endings (more details here).

:%s/<Ctrl-V><Ctrl-M>//g
:%s/\n//g

Next, I copied everything between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- and pasted it into the cert value of config.json. I had to remove the comments from config.json for everything to work.

After making these changes, I was able to run "npm install" and "npm start" and successfully login at http://localhost:3000.

Ruby

The Ruby sample uses Sinatra, omniauth and omniauth-saml. To run the okta-ruby-sinatra application, I had to start by installing Bundler.

sudo gem install bundler

Then I installed all the required gems for this project using the following command.

bundle install

This resulted in the following error:

An error occurred while installing nokogiri (1.6.1), and Bundler cannot continue.
Make sure that `gem install nokogiri -v '1.6.1'` succeeds before bundling

I tried Bundler's suggestion, but it failed:

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

    /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby extconf.rb
mkmf.rb can't find header files for ruby at /System/Library/Frameworks/Ruby.
framework/Versions/2.0/usr/lib/ruby/include/ruby.h

I then tried upgrading to Xcode 6.1.1. I received the same error and running "bundle update sinatra" and "sudo gem update --system" didn't help anything. I found an old Stack Overflow answer that suggested running "xcode-select --install" to install Xcode's Command Line Developer Tools. After doing so, I ran "sudo gcc" to accept to all Apple's licensing agreements. I ran "bundle install" again and this time it failed with the following error:

-----
libxml2 is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
-----
...
An error occurred while installing nokogiri (1.6.1), and Bundler cannot continue.
Make sure that `gem install nokogiri -v '1.6.1'` succeeds before bundling.

I tried Bundler's suggested again: "sudo gem install nokogiri -v '1.6.1'". This didn't work, so I tried "bundle update" and it finally worked. I ran "bundle install" for the final time, followed by "ruby app.rb". WEBrick started and I created a "Okta Ruby Example" application on Okta with the following settings.

Setting	Value
Application label	Okta Ruby Example
Force Authentication	false
Post Back URL	http://localhost:4567/auth/saml/callback
Name ID Format	EmailAddress
Recipient	http://localhost:4567
Audience Restriction	http://localhost:4567
authnContextClassRef	PasswordProtectedTransport
Response	Signed
Assertion	Signed
Request	Compressed
Destination	http://localhost:4567/auth/saml/callback
Attribute Statements	email\|${user.email},firstName\|${user.firstName}

To configure Sinatra with Otka's settings, I started by renaming the config.yml.sample file:

mv config.yml.sample config.yml

In Otka's Admin UI for the application, I clicked on the "Sign On" tab and clicked its "View Setup Instructions" button. I copied the "Redirect Login URL" value and copied it into config.yml's target_url value. I then downloaded the certificate and ran the the following command in the directory I downloaded it to.

openssl x509 -noout -fingerprint -in "okta.cert"

I copied the fingerprint into config.yml's fingerprint value and restarted the app. I opened http://localhost:4567 in my browser and was able to successfully login.

JRuby

To start with JRuby, I first read the project's README. It mentioned issues with "nokogiri" and explains the project contains a patched release of nokogiri 1.6.0. Since I knew there was a later release, I modified Gemfile and removed the version and path information from the last line. I copied the config.yml from the Ruby project and ran the following commands to install Bundler, the project's dependencies and start the app.

jruby -S gem install bundler
jruby -S bundle install

Running the second command resulted in the following error:

Your jruby version is 1.7.18, but your Gemfile specified jruby 1.7.4

I modified Gemfile to specify "1.7.18" and tried again. This time it worked. I started the application using the following command:

jruby app.rb

NOTE: If you see the the following in your browser window, it means you forgot to copy config.yml from the Ruby project.

undefined method `auth' for Sinatra::Application:Class

When I tried to login at http://localhost:4567, I saw an infinite redirect and the following error in my console.

W, [2015-01-08T08:53:22.514000 #56144]  WARN -- : attack prevented by Rack::Protection::SessionHijacking
0:0:0:0:0:0:0:1 - - [08/Jan/2015 08:53:22] "GET / HTTP/1.1" 302 - 0.0190
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:53:22 MST] "GET / HTTP/1.1" 302 0

Stack Overflow indicated this is a problem caused by an old version of rack-protection. Running "jruby -S bundle update rack-protection" updated the project to use rack-protection 1.5.3 (was 1.5.1). After restarting and trying again, I received the following error:

I, [2015-01-08T08:59:32.679000 #56176]  INFO -- omniauth: (saml) Callback phase initiated.
E, [2015-01-08T08:59:34.747000 #56176] ERROR -- omniauth: (saml) Authentication failure! invalid_ticket: Onelogin::Saml::ValidationError, Digest mismatch
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:59:34 -0700] "POST /auth/saml/callback HTTP/1.1" 302 9 2.0760
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:59:34 -0700] "GET /auth/failure?message=invalid_ticket&strategy=saml HTTP/1.1" 404 449 0.0080
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:59:34 MST] "GET /auth/failure?message=invalid_ticket&strategy=saml HTTP/1.1" 404 449
- -> /auth/failure?message=invalid_ticket&strategy=saml
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:59:34 -0700] "GET /__sinatra__/404.png HTTP/1.1" 200 18893 0.0200
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:59:32 MST] "POST /auth/saml/callback HTTP/1.1" 302 9
- -> /auth/saml/callback
0:0:0:0:0:0:0:1 - - [08/Jan/2015:08:59:34 MST] "GET /__sinatra__/404.png HTTP/1.1" 200 18893
http://localhost:4567/auth/failure?message=invalid_ticket&strategy=saml -> /__sinatra__/404.png

At this point, the only thing different from my working version and my old laptop was the version of Java. My old laptop had "build 1.8.0_05-b13", so I upgraded to the latest version of Java 8 (update 25). This didn't help, so I tried updating all bundles with "jruby -S bundle update". This failed too, so I figured I'd try to use the version of JRuby that was on my working laptop (version 1.7.16.1). I installed Homebrew, ran "brew install jruby", removed the newer version from my path and downgraded the version in Gemfile. I had to re-install Bundler and the projects dependencies with the following commands.

jruby -S gem install bundler
jruby -S bundle install

Same error again. I reverted Gemfile.lock and ran the only bundle update command I'd run on my working laptop:

$ jruby -S bundle update sinatra

Unfortunately, this still didn't fix the issue. I copied the project from my working laptop and tried running that project. It failed, proving that it was an environment issue, not a project/code issue. I tried rebooting and when that didn't work, I gave up. It's pretty strange this didn't work on a fresh Yosemite install - it took me less than 10 minutes to get it working originally.

Spring

The Spring sample I got working with Okta was Vincenzo De Notaris' spring-boot-security-saml-sample. This project uses Spring Boot and Spring Security SAML. I created a "Okta Spring Example" application on Okta with the following settings.

Setting	Value
Application label	Okta Spring Example
Force Authentication	false
Post Back URL	http://localhost:8080/saml/SSO
Name ID Format	EmailAddress
Recipient	http://localhost:8080/saml/SSO
Audience Restriction	com:vdenotaris:spring:sp
authnContextClassRef	PasswordProtectedTransport
Response	Signed
Assertion	Signed
Request	Uncompressed
Destination	http://localhost:8080/saml/SSO
Attribute Statements	email\|${user.email},firstName\|${user.firstName}

The biggest thing I learned while trying to get these values correct was that Request needs to be set to Uncompressed.

After cloning the GitHub project to my hard drive, I added a new SSO provider by adding a new bean to WebSecurityConfig.java. The URL I got from Okta's Admin UI: Sign On > View Setup Instructions > Public Link (near the bottom of the page).

@Bean(name = "idp-okta")
public ExtendedMetadataDelegate ssoOktaExtendedMetadataProvider()
      throws MetadataProviderException {
    @SuppressWarnings({ "deprecation"})
    HTTPMetadataProvider httpMetadataProvider
          = new HTTPMetadataProvider("https://client.okta.com/app/random-key-here/sso/saml/metadata", 5000);
    httpMetadataProvider.setParserPool(parserPool());
    ExtendedMetadataDelegate extendedMetadataDelegate =
          new ExtendedMetadataDelegate(httpMetadataProvider, extendedMetadata());
    extendedMetadataDelegate.setMetadataTrustCheck(false);
    extendedMetadataDelegate.setMetadataRequireSignature(false);
    return extendedMetadataDelegate;
}

For the SSL connection to work, I had to download the certificate and import it into the application's keystore. To do this in Chrome, I went to https://client.okta.com, clicked on the lock icon in the address bar, then dragged/dropped the certificate image to my desktop. This resulted in a *.okta.com.cer file on my desktop. I added it to the keystore using the following commands (thanks Stack Overflow).

keytool -importcert -file ~/Desktop/\*.okta.com.cer -keystore src/main/resources/saml/samlKeystore.jks

When prompted for the password, I entered "nalle123". This value is specified in WebSecurityConfig.java's keyManager bean. I then added this provider to the list of providers in the metadata bean.

@Bean
@Qualifier("metadata")
public CachingMetadataManager metadata() throws MetadataProviderException {
        List<MetadataProvider> providers = new ArrayList<MetadataProvider>();
    providers.add(ssoOktaExtendedMetadataProvider());
    providers.add(ssoCircleExtendedMetadataProvider());
    return new CachingMetadataManager(providers);
}

After making these changes, I started the application using "mvn spring-boot:run". I navigated to http://localhost:8080, chose Okta as my Idp and logged in successfully!

Summary

This article shows you how I got Node.js, Ruby and Spring applications working with Okta's SAML support. My experience with this when I first tried it: Node was super-easy, Ruby was a bit more difficult, JRuby was a cinch and Spring took several days. As you can tell from this article, Ruby/JRuby were the most difficult to make work on a clean machine.

All in all, working with Okta has been a pleasant experience so far. Hopefully this article helps make it a good experience for you as well.

AppFuse, Reduced

Matt Raible — Tue, 16 Dec 2014 06:03:31 -0700

In November, I had some time off between clients. To occupy my time, I exercised my body and brain a bit. I spent a couple hours a day exercising and a few hours a day working on AppFuse. AppFuse isn't used to start projects nearly as much as it once was. This makes sense since there's been a ton of innovation on the JVM and there's lots of get-started-quickly frameworks now. Among my favorites are Spring Boot, JHipster, Grails and Play.

You can see that AppFuse's community activity has decreased quite a bit over the years by looking at its mailing list traffic.

Even though there's not a lot of users talking on the mailing list, it still seems to get quite a few downloads from Maven Central.

I think the biggest value that AppFuse provides now is a learning tool for those who work on it. Also, it's a good place to show other developers how they can evolve with open source frameworks (e.g. Spring, Hibernate, JSF, Tapestry, Struts) over several years. Showing how we migrated to Spring MVC Test, for example, might be useful. The upcoming move to Spring Data instead of our Generic DAO solution might be interesting as well.

Regardless of whether AppFuse is used a lot or not, it should be easy to maintain. Over the several weeks, I made some opinionated changes and achieved some pretty good progress on simplifying things and making the project easier to maintain. The previous structure has a lot of duplicate versions, properties and plugin configurations between different projects. I was able to leverage Maven's inheritance model to make a number of improvements:

Changed AppFuse's parent to be based on the Spring IO Platform. This project is a dependency manager that defines version numbers for open source projects that work well with Spring.
Defined plugins, their versions and configurations in <pluginManagement>.
Defined dependencies, their versions and exclusions in <dependencyManagement>.
Simplified archetypes so new projects have minimal dependencies. For example, here's a basic project's pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.company</groupId>
    <artifactId>springmvc-project</artifactId>
    <packaging>war</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>AppFuse Spring MVC Application</name>

    <parent>
        <groupId>org.appfuse</groupId>
        <artifactId>appfuse-web</artifactId>
        <version>3.5.0-SNAPSHOT</version>
    </parent>

    <build>
        <plugins>
            <plugin>
                <groupId>de.juplo</groupId>
                <artifactId>hibernate4-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>dbunit-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>org.appfuse</groupId>
            <artifactId>appfuse-${web.framework}</artifactId>
            <version>${appfuse.version}</version>
            <type>pom</type>
        </dependency>
    </dependencies>

    <properties>
        <amp.genericCore>true</amp.genericCore>
        <amp.fullSource>false</amp.fullSource>
        <dao.framework>hibernate</dao.framework>
        <db.name>mydatabase</db.name>
        <web.framework>spring</web.framework>

        <!-- Framework/Plugin versions -->
        <appfuse.version>3.5.0-SNAPSHOT</appfuse.version>
        <java.version>1.7</java.version>
    </properties>

    <profiles>
        <profile>
            <id>itest</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.cargo</groupId>
                        <artifactId>cargo-maven2-plugin</artifactId>
                    </plugin>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>webtest-maven-plugin</artifactId>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

    <reporting>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>webtest-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </reporting>
</project>

The pull request for these changes says it all:

AppFuse +4,822 -14,369
AppFuse Light +776 -4,687

That's right, I was able to eliminate a good chunk of code without affecting any of AppFuse's functionality¹. I think we can all agree that less code == easier maintenance. This theme will continue as we work on future releases.

Other improvements include migrating all tests to use JUnit4, integrating Spring MVC Test, and configuring the surefire plugin to run tests in parallel. I also The build-helper-maven-plugin is now used to find open ports for Cargo to run and a lot of testing was done to ensure you can build/test multiple AppFuse-derived projects at the same time. Finally, I migrated to the hibernate4-maven-plugin and upgraded to Tapestry 5.4.

In the next version of AppFuse, I plan to remove as much XML as possible - moving all of the configuration to Spring's JavaConfig. We'll also be moving to Java 8 as a minimum. I'm even considering getting rid of all the pom.xml files in favor of another build language that requires less code.

In other words, the upcoming 3.5 release will be the last release that supports Java 7 and uses Spring's XML for configuration. AppFuse 4.0 will strive for #NoXML. The project's roadmap has more details on additional hopes and dreams.

We'd love to hear your feedback on these change. Do you like the simplification theme? Are you OK with having AppFuse as a parent in your projects?

1. For project and code stats, see AppFuse on Open Hub.

Devoxx4Kids Denver: Having fun with littleBits

Matt Raible — Tue, 2 Dec 2014 12:10:49 -0700

A little more than a week ago, on a beautiful Saturday morning, a number of Denver kids converged at Assembly to learn about hardware concepts with littleBits. This meetup was a bit different than our last meeting in that the kids built stuff with their hands rather than on computers.

The workshop was taught by Juan Sanchez of Tack Mobile. Juan did an excellent job of keeping his presentation short and sweet and got the kids building things within the first hour. The event space provided by Assembly was excellent and we look forward to December's Greenfoot Workshop at the same location.

Dan Allen was a big help in planning this meetup. Dan put me in touch with Corey Davis from Denver's Turing School. Corey introduced me to Rachel Warbelow, the pedagogy lead at Turing. Rachel not only volunteered at the event, but she brought a number of students with her to help out. There were a couple other volunteers as well, including my daughter's video game programming teacher from Campus Middle School. Everything went quite smooth with so much help. Thanks all!

Devoxx4Kids USA now owns a littleBits workshop set thanks to a generous donation from Raible Designs. If you're running a Devoxx4Kids meetup with littleBits, please let me know. I'd be happy to ship the set for you to use.

Juan's presentation on hardware concepts can be found on SlideShare or viewed below.

Thanks to McGinity Photo for all the pictures above. You find many more on Flickr.

Our next meetup will be a Greenfoot workshop with Steve Pousty on December 13th. Please RSVP if you'd like to attend!

Building a REST API with JAXB, Spring Boot and Spring Data

Matt Raible — Wed, 29 Oct 2014 05:52:37 -0600

If someone asked you to develop a REST API on the JVM, which frameworks would you use? I was recently tasked with such a project. My client asked me to implement a REST API to ingest requests from a 3rd party. The project entailed consuming XML requests, storing the data in a database, then exposing the data to internal application with a JSON endpoint. Finally, it would allow taking in a JSON request and turning it into an XML request back to the 3rd party.

With the recent release of Apache Camel 2.14 and my success using it, I started by copying my Apache Camel / CXF / Spring Boot project and trimming it down to the bare essentials. I whipped together a simple Hello World service using Camel and Spring MVC. I also integrated Swagger into both. Both implementations were pretty easy to create (sample code), but I decided to use Spring MVC. My reasons were simple: its REST support was more mature, I knew it well, and Spring MVC Test makes it easy to test APIs.

Camel's Swagger support without web.xml
As part of the aforementioned spike, I learned out how to configure Camel's REST and Swagger support using Spring's JavaConfig and no web.xml. I made this into a sample project and put it on GitHub as camel-rest-swagger.

This article shows how I built a REST API with Java 8, Spring Boot/MVC, JAXB and Spring Data (JPA and REST components). I stumbled a few times while developing this project, but figured out how to get over all the hurdles. I hope this helps the team that's now maintaining this project (my last day was Friday) and those that are trying to do something similar.

XML to Java with JAXB

The data we needed to ingest from a 3rd party was based on the NCPDP Standards. As a member, we were able to download a number of XSD files, put them in our project and generate Java classes to handle the incoming/outgoing requests. I used the maven-jaxb2-plugin to generate the Java classes.

<plugin>
    <groupId>org.jvnet.jaxb2.maven2</groupId>
    <artifactId>maven-jaxb2-plugin</artifactId>
    <version>0.8.3</version>
    <executions>
        <execution>
            <goals>
                <goal>generate</goal>
            </goals>
            <configuration>
                <args>
                    <arg>-XtoString</arg>
                    <arg>-Xequals</arg>
                    <arg>-XhashCode</arg>
                    <arg>-Xcopyable</arg>
                </args>
                <plugins>
                    <plugin>
                        <groupId>org.jvnet.jaxb2_commons</groupId>
                        <artifactId>jaxb2-basics</artifactId>
                        <version>0.6.4</version>
                    </plugin>
                </plugins>
                <schemaDirectory>src/main/resources/schemas/ncpdp</schemaDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

The first error I ran into was about a property already being defined.

[INFO] --- maven-jaxb2-plugin:0.8.3:generate (default) @ spring-app ---
[ERROR] Error while parsing schema(s).Location [ file:/Users/mraible/dev/spring-app/src/main/resources/schemas/ncpdp/structures.xsd{1811,48}].
com.sun.istack.SAXParseException2; systemId: file:/Users/mraible/dev/spring-app/src/main/resources/schemas/ncpdp/structures.xsd;
    lineNumber: 1811; columnNumber: 48; Property "MultipleTimingModifierAndTimingAndDuration" is already defined.
    Use <jaxb:property> to resolve this conflict.
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:86)

I was able to workaround this by upgrading to maven-jaxb2-plugin version 0.9.1. I created a controller and stubbed out a response with hard-coded data. I confirmed the incoming XML-to-Java marshalling worked by testing with a sample request provided by our 3rd party customer. I started with a curl command, because it was easy to use and could be run by anyone with the file and curl installed.

curl -X POST -H 'Accept: application/xml' -H 'Content-type: application/xml' \
--data-binary @sample-request.xml http://localhost:8080/api/message -v

This is when I ran into another stumbling block: the response wasn't getting marshalled back to XML correctly. After some research, I found out this was caused by the lack of @XmlRootElement annotations on my generated classes. I posted a question to Stack Overflow titled Returning JAXB-generated elements from Spring Boot Controller. After banging my head against the wall for a couple days, I figured out the solution.

I created a bindings.xjb file in the same directory as my schemas. This causes JAXB to generate @XmlRootElement on classes.

<?xml version="1.0"?>
<jxb:bindings version="1.0"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema"
              xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
              xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd">

    <jxb:bindings schemaLocation="transport.xsd" node="/xsd:schema">
        <jxb:globalBindings>
            <xjc:simple/>
        </jxb:globalBindings>
    </jxb:bindings>
</jxb:bindings>

To add namespaces prefixes to the returned XML, I had to modify the maven-jaxb2-plugin to add a couple arguments.

<arg>-extension</arg>
<arg>-Xnamespace-prefix</arg>

And add a dependency:

<dependencies>
    <dependency>
        <groupId>org.jvnet.jaxb2_commons</groupId>
        <artifactId>jaxb2-namespace-prefix</artifactId>
        <version>1.1</version>
    </dependency>
</dependencies>

Then I modified bindings.xjb to include the package and prefix settings. I also moved <xjc:simple/> into a global setting. I eventually had to add prefixes for all schemas and their packages.

<?xml version="1.0"?>
<bindings version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://java.sun.com/xml/ns/jaxb"
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:namespace="http://jaxb2-commons.dev.java.net/namespace-prefix"
          xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd
              http://jaxb2-commons.dev.java.net/namespace-prefix http://java.net/projects/jaxb2-commons/sources/svn/content/namespace-prefix/trunk/src/main/resources/prefix-namespace-schema.xsd">

    <globalBindings>
        <xjc:simple/>
    </globalBindings>

    <bindings schemaLocation="transport.xsd" node="/xsd:schema">
        <schemaBindings>
            <package name="org.ncpdp.schema.transport"/>
        </schemaBindings>
        <bindings>
            <namespace:prefix name="transport"/>
        </bindings>
    </bindings>
</bindings>

I learned how to add prefixes from the namespace-prefix plugins page.

Finally, I customized the code-generation process to generate Joda Time's DateTime instead of the default XMLGregorianCalendar. This involved a couple custom XmlAdapters and a couple additional lines in bindings.xjb. You can see the adapters and bindings.xjb with all necessary prefixes in this gist. Nicolas Fränkel's Customize your JAXB bindings was a great resource for making all this work.

I wrote a test to prove that the ingest API worked as desired.

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Application.class)
@WebAppConfiguration
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS)
public class InitiateRequestControllerTest {

    @Inject
    private InitiateRequestController controller;

    private MockMvc mockMvc;

    @Before
    public void setup() {
        MockitoAnnotations.initMocks(this);
        this.mockMvc = MockMvcBuilders.standaloneSetup(controller).build();
    }

    @Test
    public void testGetNotAllowedOnMessagesAPI() throws Exception {
        mockMvc.perform(get("/api/initiate")
                .accept(MediaType.APPLICATION_XML))
                .andExpect(status().isMethodNotAllowed());
    }

    @Test
    public void testPostPaInitiationRequest() throws Exception {
        String request = new Scanner(new ClassPathResource("sample-request.xml").getFile()).useDelimiter("\\Z").next();

        mockMvc.perform(post("/api/initiate")
                .accept(MediaType.APPLICATION_XML)
                .contentType(MediaType.APPLICATION_XML)
                .content(request))
                .andExpect(status().isOk())
                .andExpect(content().contentType(MediaType.APPLICATION_XML))
                .andExpect(xpath("/Message/Header/To").string("3rdParty"))
                .andExpect(xpath("/Message/Header/SenderSoftware/SenderSoftwareDeveloper").string("HID"))
                .andExpect(xpath("/Message/Body/Status/Code").string("010"));
    }
}

Spring Data for JPA and REST

With JAXB out of the way, I turned to creating an internal API that could be used by another application. Spring Data was fresh in my mind after reading about it last summer. I created classes for entities I wanted to persist, using Lombok's @Data to reduce boilerplate.

I read the Accessing Data with JPA guide, created a couple repositories and wrote some tests to prove they worked. I ran into an issue trying to persist Joda's DateTime and found Jadira provided a solution.

I added its usertype.core as a dependency to my pom.xml:

<dependency>
    <groupId>org.jadira.usertype</groupId>
    <artifactId>usertype.core</artifactId>
    <version>3.2.0.GA</version>
</dependency>

... and annotated DateTime variables accordingly.

@Column(name = "last_modified", nullable = false)
@Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime")
private DateTime lastModified;

With JPA working, I turned to exposing REST endpoints. I used Accessing JPA Data with REST as a guide and was looking at JSON in my browser in a matter of minutes. I was surprised to see a "profile" service listed next to mine, and posted a question to the Spring Boot team. Oliver Gierke provided an excellent answer.

Swagger

Spring MVC's integration for Swagger has greatly improved since I last wrote about it. Now you can enable it with a @EnableSwagger annotation. Below is the SwaggerConfig class I used to configure Swagger and read properties from application.yml.

@Configuration
@EnableSwagger
public class SwaggerConfig implements EnvironmentAware {
	public static final String DEFAULT_INCLUDE_PATTERN = "/api/.*";

	private RelaxedPropertyResolver propertyResolver;

	@Override
	public void setEnvironment(Environment environment) {
		this.propertyResolver = new RelaxedPropertyResolver(environment, "swagger.");
	}

	/**
	 * Swagger Spring MVC configuration
	 */
	@Bean
	public SwaggerSpringMvcPlugin swaggerSpringMvcPlugin(SpringSwaggerConfig springSwaggerConfig) {
		return new SwaggerSpringMvcPlugin(springSwaggerConfig)
				.apiInfo(apiInfo())
				.genericModelSubstitutes(ResponseEntity.class)
				.includePatterns(DEFAULT_INCLUDE_PATTERN);
	}

	/**
	 * API Info as it appears on the swagger-ui page
	 */
	private ApiInfo apiInfo() {
		return new ApiInfo(
				propertyResolver.getProperty("title"),
				propertyResolver.getProperty("description"),
				propertyResolver.getProperty("termsOfServiceUrl"),
				propertyResolver.getProperty("contact"),
				propertyResolver.getProperty("license"),
				propertyResolver.getProperty("licenseUrl"));
	}
}

After getting Swagger to work, I discovered that endpoints published with @RepositoryRestResource aren't picked up by Swagger. There is an open issue for Spring Data support in the swagger-springmvc project.

Liquibase Integration

I configured this project to use H2 in development and PostgreSQL in production. I used Spring profiles to do this and copied XML/YAML (for Maven and application*.yml files) from a previously created JHipster project.

Next, I needed to create a database. I decided to use Liquibase to create tables, rather than Hibernate's schema-export. I chose Liquibase over Flyway based of discussions in the JHipster project. To use Liquibase with Spring Boot is dead simple: add the following dependency to pom.xml, then place changelog files in src/main/resources/db/changelog.

<dependency>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-core</artifactId>
</dependency>

I started by using Hibernate's schema-export and changing hibernate.ddl-auto to "create-drop" in application-dev.yml. I also commented out the liquibase-core dependency. Then I setup a PostgreSQL database and started the app with "mvn spring-boot:run -Pprod".

I generated the liquibase changelog from an existing schema using the following command (after downloading and installing Liquibase).

liquibase --driver=org.postgresql.Driver --classpath="/Users/mraible/.m2/repository/org/postgresql/postgresql/9.3-1102-jdbc41/postgresql-9.3-1102-jdbc41.jar:/Users/mraible/snakeyaml-1.11.jar" --changeLogFile=/Users/mraible/dev/spring-app/src/main/resources/db/changelog/db.changelog-02.yaml --url="jdbc:postgresql://localhost:5432/mydb" --username=user --password=pass generateChangeLog

I did find one bug - the generateChangeLog command generates too many constraints in version 3.2.2. I was able to fix this by manually editing the generated YAML file.

Tip: If you want to drop all tables in your database to verify Liquibase creation is working in PostgeSQL, run the following commands:

psql -d mydb
drop schema public cascade;
create schema public;

After writing minimal code for Spring Data and configuring Liquibase to create tables/relationships, I relaxed a bit, documented how everything worked and added a LoggingFilter. The LoggingFilter was handy for viewing API requests and responses.

@Bean
public FilterRegistrationBean loggingFilter() {
    LoggingFilter filter = new LoggingFilter();
    FilterRegistrationBean registrationBean = new FilterRegistrationBean();
    registrationBean.setFilter(filter);
    registrationBean.setUrlPatterns(Arrays.asList("/api/*"));
    return registrationBean;
}

Accessing API with RestTemplate

The final step I needed to do was figure out how to access my new and fancy API with RestTemplate. At first, I thought it would be easy. Then I realized that Spring Data produces a HAL-compliant API, so its content is embedded inside an "_embedded" JSON key.

After much trial and error, I discovered I needed to create a RestTemplate with HAL and Joda-Time awareness.

@Bean
public RestTemplate restTemplate() {
	ObjectMapper mapper = new ObjectMapper();
	mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
	mapper.registerModule(new Jackson2HalModule());
	mapper.registerModule(new JodaModule());

	MappingJackson2HttpMessageConverter converter = new MappingJackson2HttpMessageConverter();
	converter.setSupportedMediaTypes(MediaType.parseMediaTypes("application/hal+json"));
	converter.setObjectMapper(mapper);
	StringHttpMessageConverter stringConverter = new StringHttpMessageConverter();
	stringConverter.setSupportedMediaTypes(MediaType.parseMediaTypes("application/xml"));

	List<HttpMessageConverter<?>> converters = new ArrayList<>();
	converters.add(converter);
	converters.add(stringConverter);

	return new RestTemplate(converters);
}

The JodaModule was provided by the following dependency:

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-joda</artifactId>
</dependency>

With the configuration complete, I was able to write a MessagesApiITest integration test that posts a request and retrieves it using the API. The API was secured using basic authentication, so it took me a bit to figure out how to make that work with RestTemplate. Willie Wheeler's Basic Authentication With Spring RestTemplate was a big help.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = IntegrationTestConfig.class)
public class MessagesApiITest {
    private final static Log log = LogFactory.getLog(MessagesApiITest.class);
    @Value("http://${app.host}/api/initiate")
    private String initiateAPI;
    @Value("http://${app.host}/api/messages")
    private String messagesAPI;
    @Value("${app.host}")
    private String host;
    @Inject
    private RestTemplate restTemplate;

    @Before
    public void setup() throws Exception {
        String request = new Scanner(new ClassPathResource("sample-request.xml").getFile()).useDelimiter("\\Z").next();

        ResponseEntity<org.ncpdp.schema.transport.Message> response = restTemplate.exchange(getTestUrl(initiateAPI),
                HttpMethod.POST, getBasicAuthHeaders(request), org.ncpdp.schema.transport.Message.class,
                Collections.emptyMap());
        assertEquals(HttpStatus.OK, response.getStatusCode());
    }

    @Test
    public void testGetMessages() {
        HttpEntity<String> request = getBasicAuthHeaders(null);

        ResponseEntity<PagedResources<Message>> result = restTemplate.exchange(getTestUrl(messagesAPI), HttpMethod.GET,
                request, new ParameterizedTypeReference<PagedResources<Message>>() {});
        HttpStatus status = result.getStatusCode();
        Collection<Message> messages = result.getBody().getContent();

        log.debug("messages found: " + messages.size());
        assertEquals(HttpStatus.OK, status);
        for (Message message : messages) {
            log.debug("message.id: " + message.getId());
            log.debug("message.dateCreated: " + message.getDateCreated());
        }
    }

    private HttpEntity<String> getBasicAuthHeaders(String body) {
        String plainCreds = "user:pass";
        byte[] plainCredsBytes = plainCreds.getBytes();
        byte[] base64CredsBytes = Base64.encodeBase64(plainCredsBytes);
        String base64Creds = new String(base64CredsBytes);

        HttpHeaders headers = new HttpHeaders();
        headers.add("Authorization", "Basic " + base64Creds);
        headers.add("Content-type", "application/xml");

        if (body == null) {
            return new HttpEntity<>(headers);
        } else {
            return new HttpEntity<>(body, headers);
        }
    }
}

To get Spring Data to populate the message id, I created a custom RestConfig class to expose it. I learned how to do this from Tommy Ziegler.

/**
 * Used to expose ids for resources.
 */
@Configuration
public class RestConfig extends RepositoryRestMvcConfiguration {

    @Override
    protected void configureRepositoryRestConfiguration(RepositoryRestConfiguration config) {
        config.exposeIdsFor(Message.class);
        config.setBaseUri("/api");
    }
}

Summary

This article explains how I built a REST API using JAXB, Spring Boot, Spring Data and Liquibase. It was relatively easy to build, but required some tricks to access it with Spring's RestTemplate. Figuring out how to customize JAXB's code generation was also essential to make things work.

I started developing the project with Spring Boot 1.1.7, but upgraded to 1.2.0.M2 after I found it supported Log4j2 and configuring Spring Data REST's base URI in application.yml. When I handed the project off to my client last week, it was using 1.2.0.BUILD-SNAPSHOT because of a bug when running in Tomcat.

This was an enjoyable project to work on. I especially liked how easy Spring Data makes it to expose JPA entities in an API. Spring Boot made things easy to configure once again and Liquibase seems like a nice tool for database migrations.

If someone asked me to develop a REST API on the JVM, which frameworks would I use? Spring Boot, Spring Data, Jackson, Joda-Time, Lombok and Liquibase. These frameworks worked really well for me on this particular project.

Developing Services with Apache Camel - Part IV: Load Testing and Monitoring

Matt Raible — Wed, 15 Oct 2014 10:04:01 -0600

Welcome to the final article in a series on my experience developing services with Apache Camel. I learned how to implement CXF endpoints using its Java DSL, made sure everything worked with its testing framework and integrated Spring Boot for external configuration. For previous articles, please see the following:

This article focuses on load testing and tools for monitoring application performance. In late July, I was asked to look into load testing the new Camel-based services I'd developed. My client's reason was simple: to make sure the new services were as fast as the old ones (powered by IBM Message Broker). I sent an email to the Camel users mailing list asking for advice on load testing.

I'm getting ready to put a Camel / CXF / Spring Boot application into production. Before I do, I want to load test and verify it has the same throughput as a the IBM Message Broker system it's replacing. Apparently, the old system can only do 6 concurrent connections because of remote database connectivity issues.

I'd like to write some tests that make simultaneous requests, with different data. Ideally, I could write them to point at the old system and find out when it falls over. Then I could point them at the new system and tune it accordingly. If I need to throttle because of remote connectivity issues, I'd like to know before we go to production. Does JMeter or any Camel-related testing tools allow for this?

In reply, I received suggestions for Apache's ab tool and Gatling. I'd heard of Gatling before, and decided to try it.

Gatling

I don't remember where I first heard of Gatling, but I knew it had a Scala DSL and used Akka under the covers. I generated a new project using a Maven archetype and went to work developing my first test. My approach involved three steps:

Write tests to run against current system. Find the number of concurrent requests that make it fall over.
Run tests against new system and tune accordingly.
Throttle requests if there are remote connectivity issues with 3rd parties. If I needed to throttle requests, I was planning to use Camel's Throttler.

To develop the first test, I started with Gatling's Recorder. I set it to listen on port 8000, changed my DrugServiceITest to use the same port and ran the integration test. This was a great way to get started because it recorded my requests as XML files, and used clean and concise code.

I ended up creating a parent class for all simulations and named it AbstractSimulation. This was handy because it allowed me to pass in parameters for all the values I wanted to change.

import io.gatling.core.scenario.Simulation
import io.gatling.http.Predef._

/**
 * Base Simulation class that allows passing in parameters.
 */
class AbstractSimulation extends Simulation {

  val host = System.getProperty("host", "localhost:8080")
  val serviceType = System.getProperty("service", "modern")
  val nbUsers = Integer.getInteger("users", 10).toInt
  val rampRate = java.lang.Long.getLong("ramp", 30L).toLong

  val httpProtocol = http
    .baseURL("http://" + host)
    .acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
    .doNotTrackHeader("1")
    .acceptLanguageHeader("en-US,en;q=0.5")
    .acceptEncodingHeader("gzip, deflate")
    .userAgentHeader("Gatling 2.0")

  val headers = Map(
    """Cache-Control""" -> """no-cache""",
    """Content-Type""" -> """application/soap+xml; charset=UTF-8""",
    """Pragma""" -> """no-cache""")
}

The DrugServiceSimulation.scala class posts a SOAP request over HTTP.

import io.gatling.core.Predef._
import io.gatling.http.Predef._

import scala.concurrent.duration._

class DrugServiceSimulation extends AbstractSimulation {

  val service = if ("modern".equals(serviceType)) "/api/drugs" else "/axis2/services/DrugService"

  val scn = scenario("Drug Service :: findGpiByNdc")
    .exec(http(host)
    .post(service)
    .headers(headers)
    .body(RawFileBody("DrugServiceSimulation_request.xml")))

  setUp(scn.inject(ramp(nbUsers users) over (rampRate seconds))).protocols(httpProtocol)
}

To run tests against the legacy drug service with 100 users over 60 seconds, I used the following command:

mvn test -Dhost=legacy.server:7802 -Dservice=legacy -Dusers=100 -Dramp=60

The service property's default is "modern" and determines the service's URL. To run against the local drug service with 100 users over 30 seconds, I could rely on more defaults.

mvn test -Dusers=100

The name of the simulation to run is configured in pom.xml:

<plugin>
    <groupId>io.gatling</groupId>
    <artifactId>gatling-maven-plugin</artifactId>
    <version>${gatling.version}</version>
    <configuration>
        <simulationsFolder>src/test/scala</simulationsFolder>
        <simulationClass>com.company.app.${service.name}Simulation</simulationClass>
    </configuration>
    <executions>
        <execution>
            <phase>test</phase>
            <goals>
                <goal>execute</goal>
            </goals>
        </execution>
    </executions>
</plugin>

When the simulations were done running, the console displayed a link to some pretty snazzy HTML reports. I ran simulations until things started falling over on the legacy server. That happened at around 400 requests per second (rps). When I ran them against a local instance on my fully-loaded 2013 MacBook Pro, errors started flying at 4000/rps while 3000/rps performed just fine.

Jenkins

I configured simulations to run in Jenkins with the Gatling Plugin. It's a neat plugin that allows you to record and compare results over time. After initial setup, I found I didn't use it much. Instead, I created a Google Doc with my findings and created screenshots of results so my client had it in an easy-to-read format.

Data Feeders

I knew the results of the simulations were likely skewed, since the same request was used for all users. I researched how to make dynamic requests with Gatling and found Feeders. Using a JDBC Feeder I was able make all the requests contain unique data for each user.

I added a feeder to DrugServiceSimulation, added it to the scenario and changed to use an ELFileBody so the feeder would substitute a ${NDC} variable in the XML file.

val feeder = jdbcFeeder("jdbc:db2://server:50002/database", "username", "password",
    "SELECT NDC FROM GENERICS")

val scn = scenario("Drug Service")
        .feed(feeder)
        .exec(http(host)
        .post(service)
        .headers(headers)
        .body(ELFileBody("DrugServiceSimulation_request.xml")))

I deployed the new services to a test server and ran simulations with 100 and 1000 users.

100 users over 30 seconds

Neither service had any failures with 100 users. The max response time for the legacy service was 389 ms, while the new service was 172 ms. The mean response time was lower for the legacy services: 89 ms vs. 96 ms.

1000 users over 60 seconds

When simulating 1000 users against the legacy services, 50% of the requests failed and the average response time was over 40 seconds. Against the new services, all requests succeeded and the mean response time was 100ms.

I was pumped to see the new services didn't need any additional performance enhancements. These results were enough to convince my client that Apache Camel was going to be a performant replacement for IBM Message Broker.

I wrote more simulations for another service I developed. In doing so, I discovered I missed implementing a couple custom routes for some clients. The dynamic feeders made me stumble onto this because they executed simulations for all clients. After developing the routes, the dynamic data helped me uncover a few more bugs. Using real data to load test with was very helpful in figuring out the edge-cases our routes needed to handle.

Next, I started configuring logging for our new Camel services.

Logging with Log4j2

Log4j 2.0 had just been released and my experience integrating it in AppFuse motivated me to use it for this project. I configured Spring to use Log4j 2.0 by specifying the following dependencies. Note: Spring Boot 1.2+ has support for Log4j2.

<log4j.version>2.0</log4j.version>
...

<!-- logging -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.7</version>
</dependency>
<!-- Necessary to configure Spring logging with log4j2.xml -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-jcl</artifactId>
    <version>${log4j.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-slf4j-impl</artifactId>
    <version>${log4j.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-web</artifactId>
    <version>${log4j.version}</version>
</dependency>

I created a src/main/resources/log4j2.xml file and configured a general log, as well as one for each route. I configured each route to use "log:com.company.app.route.input" and "log:com.company.app.route.output" instead of "log:input" and "log:output". This allowed the log-file-per-route configuration you see below.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Properties>
        <Property name="fileLogDir">/var/log/app-name</Property>
        <Property name="fileLogPattern">%d %p %c: %m%n</Property>
        <Property name="fileLogTriggerSize">1 MB</Property>
        <Property name="fileLogRolloverMax">10</Property>
    </Properties>
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d [%-15.15t] %-5p %-30.30c{1} %m%n"/>
        </Console>
        <RollingFile name="File" fileName="${fileLogDir}/all.log"
                         filePattern="${fileLogDir}/all-%d{yyyy-MM-dd}-%i.log">
            <PatternLayout pattern="${fileLogPattern}"/>
            <Policies>
                <SizeBasedTriggeringPolicy size="${fileLogTriggerSize}"/>
            </Policies>
            <DefaultRolloverStrategy max="${fileLogRolloverMax}"/>
        </RollingFile>
        <RollingFile name="DrugServiceFile" fileName="${fileLogDir}/drug-service.log"
                         filePattern="${fileLogDir}/drug-service-%d{yyyy-MM-dd}-%i.log">
            <PatternLayout pattern="${fileLogPattern}"/>
            <Policies>
                <SizeBasedTriggeringPolicy size="${fileLogTriggerSize}"/>
            </Policies>
            <DefaultRolloverStrategy max="${fileLogRolloverMax}"/>
        </RollingFile>
        <!-- Add a RollingFile for each route -->
    </Appenders>

    <Loggers>
        <Logger name="org.apache.camel" level="info"/>
        <Logger name="org.springframework" level="error"/>
        <Logger name="com.company.app" level="info"/>

        <Root level="error">
            <AppenderRef ref="Console"/>
            <AppenderRef ref="File"/>
        </Root>

        <Logger name="com.company.app.drugs" level="debug">
            <AppenderRef ref="DrugServiceFile"/>
        </Logger>
        <!-- Add a Logger for each route -->
    </Loggers>
</Configuration>

I did run into some issues with this configuration:

The /var/log/app-name directory has to exist or there's a stacktrace on startup and no logs are written.
When deploy from Jenkins, I ran into permissions issues between deploys. To fix this, I chowned the directory before restarting Tomcat.
```
chown -R tomcat /var/log/app-name
/etc/init.d/tomcat start
```

Monitoring

While I was configuring the new services on our test server, I also installed hawtio at /console. I had previously configured it to run in Tomcat when running "mvn tomcat7:run":

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.2</version>
    <configuration>
        <path>/</path>
        <webapps>
            <webapp>
                <contextPath>/console</contextPath>
                <groupId>io.hawt</groupId>
                <artifactId>hawtio-web</artifactId>
                <version>1.4.19</version>
                <type>war</type>
                <asWebapp>true</asWebapp>
            </webapp>
        </webapps>
    </configuration>
    ...
</plugin>

hawtio has a Camel plugin that's pretty slick. It shows all your routes and their runtime metrics; you can even edit the source code for routes. Even though I used a Java DSL, my routes are only editable as XML in hawtio. Claus Ibsen has a good post on Camel's new Metrics Component. I'd like to learn how to build a custom dashboard for hawtio - Claus's example looks pretty nice.

The Spring Boot plugin for hawtio is not nearly as graphic intensive. Instead, it just displays metrics and their values in a table format.

There's some good-looking Spring Boot Admin UIs out there, notably JHipster's and the one in spring-boot-admin. I hope the hawtio Spring Boot plugin gets prettier as it matures.

I wanted more than just monitoring, I wanted alerts when something went wrong. For that, I installed New Relic on our Tomcat server. I'm fond of getting the Monday reports, but they only showed activity when I was load testing.

I believe all these monitoring tools will be very useful once the app is in production. My last day with this client is next Friday, October 24. I'm trying to finish up the last couple of services this week and next. With any luck, their IBM Message Broker will be replaced this year.

Summary

This article shows how to use Gatling to load test a SOAP service and how to configure Log4j2 with Spring Boot. It also shows how hawtio can help monitor and configure a Camel application. I hope you enjoyed reading this series on what I learned about developing with Camel over the past several months. If you have stories about your experience with Camel (or similar integration frameworks), Gatling, hawtio or New Relic, I'd love to hear them.

It's been a great experience and I look forward to developing solid apps, built on open source, for my next client. I'd like to get back into HTML5, AngularJS and mobile development. I've had a good time with Spring Boot and JHipster this year and hope to use them again. I find myself using Java 8 more and more; my ideal next project would embrace it as a baseline. As for Scala and Groovy, I'm still a big fan and believe I can develop great apps with them.

If you're looking for a UI/API Architect that can help accelerate your projects, please let me know! You can learn more about my extensive experience from my LinkedIn profile.

Developing Services with Apache Camel - Part III: Integrating Spring 4 and Spring Boot

Matt Raible — Wed, 8 Oct 2014 07:13:18 -0600

This article is the third in a series on Apache Camel and how I used it to replace IBM Message Broker for a client. I used Apache Camel for several months this summer to create a number of SOAP services. These services performed various third-party data lookups for our customers. For previous articles, see Part I: The Inspiration and Part II: Creating and Testing Routes.

In late June, I sent an email to my client's engineering team. Its subject: "External Configuration and Microservices". I recommended we integrate Spring Boot into the Apache Camel project I was working on. I told them my main motivation was its external configuration feature. I also pointed out its container-less WAR feature, where Tomcat (or Jetty) is embedded in the WAR and you can start your app with "java -jar appname.war". I mentioned microservices and that Spring Boot would make it easy to split the project into a project-per-service structure if we wanted to go that route. I then asked two simple questions:

Is it OK to integrate Spring Boot?
Should I split the project into microservices?

Both of these suggestions were well received, so I went to work.

Spring 4

Before I integrated Spring Boot, I knew I had to upgrade to Spring 4. The version of Camel I was using (2.13.1) did not support Spring 4. I found issue CAMEL-7074 (Support spring 4.x) and added a comment to see when it would be fixed. After fiddling with dependencies and trying Camel 2.14-SNAPSHOT, I was able to upgrade to CXF 3.0. However, this didn't solve my problem. There were some API uncompatible changes between Spring 3.3.x and Spring 4.0.x and the camel-test-spring module wouldn't work with both. I proposed the following:

I think the easiest way forward is to create two modules: camel-test-spring and camel-test-spring3. The former compiles against Spring 4 and the latter against Spring 3. You could switch it so camel-test-spring defaults to Spring 3, but camel-test-spring4 doesn't seem to be forward-looking, as you hopefully won't need a camel-test-spring5.

I've made this change in a fork and it works in my project. I can upgrade to Camel 2.14-SNAPSHOT and CXF 3.0 with Spring 3.2.8 (by using camel-test-spring3). I can also upgrade to Spring 4 if I use the upgraded camel-test-spring.

Here's a pull request that has this change: https://github.com/apache/camel/pull/199

The Camel team integrated my suggested change a couple weeks later. Unfortunately, a similar situation happened with Spring 4.1, so you'll have to wait for Camel 2.15 if you want to use Spring 4.1.

After making a patched 2.14-SNAPSHOT version available to my project, I was able to upgrade to Spring 4 and CXF 3 with a few minor changes to my pom.xml.

    <properties>
      <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
      <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
-     <camel.version>2.13.1</camel.version>
-     <cxf.version>2.7.11</cxf.version>
-     <spring.version>3.2.8.RELEASE</spring.version>
+     <camel.version>2.14-SNAPSHOT</camel.version>
+     <cxf.version>3.0.0</cxf.version>
+     <spring.version>4.0.5.RELEASE</spring.version>
    </properties>
...
+      <!-- upgrade camel-spring dependencies -->
+      <dependency>
+         <groupId>org.springframework</groupId>
+         <artifactId>spring-context</artifactId>
+         <version>${spring.version}</version>
+      </dependency>
+      <dependency>
+         <groupId>org.springframework</groupId>
+         <artifactId>spring-aop</artifactId>
+         <version>${spring.version}</version>
+      </dependency>
+      <dependency>
+         <groupId>org.springframework</groupId>
+         <artifactId>spring-tx</artifactId>
+         <version>${spring.version}</version>
+      </dependency>

I also had to change some imports for CXF 3.0 since it includes a new major version of Apache WSS4J (2.0.0).

-import org.apache.ws.security.handler.WSHandlerConstants;
+import org.apache.wss4j.dom.handler.WSHandlerConstants;
...
-import org.apache.ws.security.WSPasswordCallback;
+import org.apache.wss4j.common.ext.WSPasswordCallback;

After getting everything upgraded, I continued developing services for the next couple weeks.

Spring Boot

In late July, I integrated Spring Boot. It was fairly straightforward and mostly consisted of adding/removing dependencies and removing versions already defined in Boot's starter-parent.

+   <parent>
+      <groupId>org.springframework.boot</groupId>
+      <artifactId>spring-boot-starter-parent</artifactId>
+      <version>1.1.4.RELEASE</version>
+   </parent>
...
       <cxf.version>3.0.1</cxf.version>
+      <java.version>1.7</java.version>
+      <servlet-api.version>3.1.0</servlet-api.version>
       <spring.version>4.0.6.RELEASE</spring.version>
...
-            <artifactId>maven-compiler-plugin</artifactId>
-            <version>2.5.1</version>
-            <configuration>
-               <source>1.7</source>
-               <target>1.7</target>
-            </configuration>
-         </plugin>
-         <plugin>
-            <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-resources-plugin</artifactId>
          </plugin>
+         <plugin>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-maven-plugin</artifactId>
+         </plugin>
       </plugins>
    </build>

    <dependencies>
+      <!-- spring boot -->
+      <dependency>
+         <groupId>org.springframework.boot</groupId>
+         <artifactId>spring-boot-starter-actuator</artifactId>
+         <exclusions>
+            <exclusion>
+               <groupId>org.springframework.boot</groupId>
+               <artifactId>spring-boot-starter-logging</artifactId>
+            </exclusion>
+         </exclusions>
+      </dependency>
+      <dependency>
+         <groupId>org.springframework.boot</groupId>
+         <artifactId>spring-boot-starter-log4j</artifactId>
+      </dependency>
+      <dependency>
+         <groupId>org.springframework.boot</groupId>
+         <artifactId>spring-boot-starter-tomcat</artifactId>
+         <scope>provided</scope>
+      </dependency>
+      <dependency>
+         <groupId>org.springframework.boot</groupId>
+         <artifactId>spring-boot-starter-web</artifactId>
+      </dependency>
       <!-- camel -->
...
-      <!-- upgrade camel-spring dependencies -->
-      <dependency>
-         <groupId>org.springframework</groupId>
-         <artifactId>spring-context</artifactId>
-         <version>${spring.version}</version>
-      </dependency>
-      <dependency>
-         <groupId>org.springframework</groupId>
-         <artifactId>spring-aop</artifactId>
-         <version>${spring.version}</version>
-      </dependency>
-      <dependency>
-         <groupId>org.springframework</groupId>
-         <artifactId>spring-tx</artifactId>
-         <version>${spring.version}</version>
-      </dependency>
...
-      <!-- logging -->
-      <dependency>
-         <groupId>org.slf4j</groupId>
-         <artifactId>slf4j-api</artifactId>
-         <version>1.7.6</version>
-      </dependency>
-      <dependency>
-         <groupId>org.slf4j</groupId>
-         <artifactId>slf4j-log4j12</artifactId>
-         <version>1.7.6</version>
-      </dependency>
-      <dependency>
-         <groupId>log4j</groupId>
-         <artifactId>log4j</artifactId>
-         <version>1.2.17</version>
-      </dependency>
-
       <!-- utilities -->
       <dependency>
          <groupId>joda-time</groupId>
          <artifactId>joda-time</artifactId>
-         <version>2.3</version>
       </dependency>
       <dependency>
          <groupId>commons-dbcp</groupId>
          <artifactId>commons-dbcp</artifactId>
-         <version>1.4</version>
...
       <!-- testing -->
       <dependency>
+         <groupId>org.springframework.boot</groupId>
+         <artifactId>spring-boot-starter-test</artifactId>
+         <exclusions>
+            <exclusion>
+               <groupId>org.springframework.boot</groupId>
+               <artifactId>spring-boot-starter-logging</artifactId>
+            </exclusion>
+         </exclusions>
+      </dependency>
+      <dependency>
-      <dependency>
-         <groupId>org.springframework</groupId>
-         <artifactId>spring-test</artifactId>
-         <version>${spring.version}</version>
-         <scope>test</scope>
-      </dependency>
-      <dependency>
-         <groupId>org.mockito</groupId>
-         <artifactId>mockito-core</artifactId>
-         <version>1.9.5</version>
-         <scope>test</scope>
-      </dependency>

Next, I deleted the AppInitializer.java class I mentioned in Part II and added an Application.java class.

import org.apache.cxf.transport.servlet.CXFServlet;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;
import org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.context.embedded.ConfigurableEmbeddedServletContainer;
import org.springframework.boot.context.embedded.EmbeddedServletContainerCustomizer;
import org.springframework.boot.context.embedded.ErrorPage;
import org.springframework.boot.context.embedded.ServletRegistrationBean;
import org.springframework.boot.context.web.SpringBootServletInitializer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.HttpStatus;

@Configuration
@EnableAutoConfiguration(exclude = {DataSourceAutoConfiguration.class,
        DataSourceTransactionManagerAutoConfiguration.class})
@ComponentScan
public class Application extends SpringBootServletInitializer {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(Application.class);
    }

    @Bean
    public ServletRegistrationBean servletRegistrationBean() {
        CXFServlet servlet = new CXFServlet();
        return new ServletRegistrationBean(servlet, "/api/*");
    }

    @Bean
    public EmbeddedServletContainerCustomizer containerCustomizer() {
        return new EmbeddedServletContainerCustomizer() {
            @Override
            public void customize(ConfigurableEmbeddedServletContainer container) {
                ErrorPage error401Page = new ErrorPage(HttpStatus.UNAUTHORIZED, "/401.html");
                ErrorPage error404Page = new ErrorPage(HttpStatus.NOT_FOUND, "/404.html");
                ErrorPage error500Page = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/500.html");
                container.addErrorPages(error401Page, error404Page, error500Page);
            }
        };
    }
}

The error pages you see configured above were configured and copied from Tim Sporcic's Custom Error Pages with Spring Boot.

Dynamic DataSources

I excluded the DataSource-related AutoConfiguration classes because this application had many datasources. It also had a requirement to allow datasources to be added on-the-fly by simply editing application.properties. I asked how to do this on Stack Overflow and received an excellent answer from Stéphane Nicoll.

Spring Boot Issues

I did encounter a couple issues after integrating Spring Boot. The first was that it was removing the content-* headers for CXF responses. This only happened when running the WAR in Tomcat and I was able to figure out a workaround with a custom ResponseWrapper and Filter. This issue was fixed in Spring Boot 1.1.6.

The other issue was that the property override feature didn't seem to work when setting environment variables. The workaround was to create a setenv.sh script in $CATALINA_HOME/bin and add the environment variables there. See section 3.4 of Tomcat 7's RUNNING.txt for more information.

SOAP Faults

After upgrading to Spring 4 and integrating Spring Boot, I continued migrating IBM Message Broker flows. My goal was to make all new services backward compatible, but I ran into an issue. With the new services, SOAP Faults were sent back to the client instead of error messages in a SOAP Message. I suggested we fix it with one of two ways:

Modify the client so it looks for SOAP Faults and handles them appropriately.
Modify the new services so messages are returned instead of faults.

For #2, I learned how do to convert from a fault to messages on the Camel user mailing list. However, the team opted to improve the client and we added fault handling there instead.

Microservice Deployment

When I first integrated Spring Boot, I was planning on splitting our project into a project-per-service. This would allow each service to evolve on its own, instead of having a monolithic war that contains all the services. In team discussions, there was some concern about the memory overhead of running multiple instances instead of one.

I pointed out an interesting thread on the Camel mailing list about deploying routes with a route-per-jvm or all in the same JVM. The recommendation from that thread was to bundle similar routes together if you were to split them.

In the end, we decided to allow our Operations team decide how they wanted to manage/deploy everything. I mentioned that Spring Boot can work with Tomcat, Jetty, JBoss and even cloud providers like Heroku and Cloud Foundry. I estimated that splitting the project apart would take less than a day, as would making it back into a monolithic WAR.

Summary

This article explains how we upgraded our Apache Camel application to Spring 4 and integrated Spring Boot. There was a bit of pain getting things to work, but nothing a few pull requests and workarounds couldn't fix. We discovered some issues with setting environment variables for Tomcat and opted not to split our project into small microservices. Hopefully this article will help people trying to Camelize a Spring Boot application .

In the next article, I'll talk about load testing with Gatling, logging with Log4j2 and monitoring with hawtio and New Relic.

Developing Services with Apache Camel - Part II: Creating and Testing Routes

Matt Raible — Tue, 30 Sep 2014 10:05:38 -0600

This article is the second in a series on Apache Camel and how I used it to replace IBM Message Broker for a client. The first article, Developing Services with Apache Camel - Part I: The Inspiration, describes why I chose Camel for this project.

To make sure these new services correctly replaced existing services, a 3-step approach was used:

Write an integration test pointing to the old service.
Write the implementation and a unit test to prove it works.
Write an integration test pointing to the new service.

I chose to start by replacing the simplest service first. It was a SOAP Service that talked to a database to retrieve a value based on an input parameter. To learn more about Camel and how it works, I started by looking at the CXF Tomcat Example. I learned that Camel is used to provide routing of requests. Using its CXF component, it can easily produce SOAP web service endpoints. An end point is simply an interface, and Camel takes care of producing the implementation.

Legacy Integration Test

I started by writing a LegacyDrugServiceTests integration test for the old drug service. I tried two different ways of testing, using WSDL-generated Java classes, as well as using JAX-WS's SOAP API. Finding the WSDL for the legacy service was difficult because IBM Message Broker doesn't expose it when adding "?wsdl" to the service's URL. Instead, I had to dig through the project files until I found it. Then I used the cxf-codegen-plugin to generate the web service client. Below is what one of the tests looked like that uses the JAX-WS API.

@Test
public void sendGPIRequestUsingSoapApi() throws Exception {
    SOAPElement bodyChildOne = getBody(message).addChildElement("gpiRequest", "m");
    SOAPElement bodyChildTwo = bodyChildOne.addChildElement("args0", "m");
    bodyChildTwo.addChildElement("NDC", "ax22").addTextNode("54561237201");
    SOAPMessage reply = connection.call(message, getUrlWithTimeout(SERVICE_NAME));
    if (reply != null) {
        Iterator itr = reply.getSOAPBody().getChildElements();
        Map resultMap = TestUtils.getResults(itr);
        assertEquals("66100525123130", resultMap.get("GPI"));
    }
}

Implementing the Drug Service

In the last article, I mentioned I wanted no XML in the project. To facilitate this, I used Camel's Java DSL to define routes and Spring's JavaConfig to configure dependencies.

The first route I wrote was one that looked up a GPI (Generic Product Identifier) by NDC (National Drug Code).

@WebService
public interface DrugService {
    @WebMethod(operationName = "gpiRequest")
    GpiResponse findGpiByNdc(GpiRequest request);
}

To expose this as a web service endpoint with CXF, I needed to do two things:

Tell Spring how to configure CXF by importing "classpath:META-INF/cxf/cxf.xml" into a @Configuration class.
Configure CXF's Servlet so endpoints can be served up at a particular URL.

To satisfy item #1, I created a CamelConfig class that extends CamelConfiguration. This class allows Camel to be configured by Spring's JavaConfig. In it, I imported the CXF configuration, allowed tracing to be configured dynamically, and exposed my application.properties to Camel. I also set it up (with @ComponentScan) to look for Camel routes annotated with @Component.

@Configuration
@ImportResource("classpath:META-INF/cxf/cxf.xml")
@ComponentScan("com.raibledesigns.camel")
public class CamelConfig extends CamelConfiguration {
    @Value("${logging.trace.enabled}")
    private Boolean tracingEnabled;

    @Override
    protected void setupCamelContext(CamelContext camelContext) throws Exception {
        PropertiesComponent pc = new PropertiesComponent();
        pc.setLocation("classpath:application.properties");
        camelContext.addComponent("properties", pc);
        // see if trace logging is turned on
        if (tracingEnabled) {
            camelContext.setTracing(true);
        }
        super.setupCamelContext(camelContext);
    }

    @Bean
    public Tracer camelTracer() {
        Tracer tracer = new Tracer();
        tracer.setTraceExceptions(false);
        tracer.setTraceInterceptors(true);
        tracer.setLogName("com.raibledesigns.camel.trace");
        return tracer;
    }
}

CXF has a servlet that's responsible for serving up its services at common path. To map CXF's servlet, I leveraged Spring's WebApplicationInitializer in an AppInitializer class. I decided to serve up everything from a /api/* base URL.

package com.raibledesigns.camel.config;

import org.apache.cxf.transport.servlet.CXFServlet;
import org.springframework.web.WebApplicationInitializer;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.AnnotationConfigWebApplicationContext;

import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRegistration;

public class AppInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext servletContext) throws ServletException {
        servletContext.addListener(new ContextLoaderListener(getContext()));
        ServletRegistration.Dynamic servlet = servletContext.addServlet("CXFServlet", new CXFServlet());
        servlet.setLoadOnStartup(1);
        servlet.setAsyncSupported(true);
        servlet.addMapping("/api/*");
    }

    private AnnotationConfigWebApplicationContext getContext() {
        AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
        context.setConfigLocation("com.raibledesigns.camel.config");
        return context;
    }
}

To implement this web service with Camel, I created a DrugRoute class that extends Camel's RouteBuilder.

@Component
public class DrugRoute extends RouteBuilder {
    private String uri = "cxf:/drugs?serviceClass=" + DrugService.class.getName();

    @Override
    public void configure() throws Exception {
        from(uri)
            .recipientList(simple("direct:${header.operationName}"));
        from("direct:gpiRequest").routeId("gpiRequest")
            .process(new Processor() {
                public void process(Exchange exchange) throws Exception {
                    // get the ndc from the input
                    String ndc = exchange.getIn().getBody(GpiRequest.class).getNDC();
                    exchange.getOut().setBody(ndc);
                }
            })
            .to("sql:{{sql.selectGpi}}")
            .to("log:output")
            .process(new Processor() {
                public void process(Exchange exchange) throws Exception {
                    // get the gpi from the input
                    List<HashMap> data = (ArrayList<HashMap>) exchange.getIn().getBody();
                    DrugInfo drug = new DrugInfo();
                    if (data.size() > 0) {
                        drug = new DrugInfo(String.valueOf(data.get(0).get("GPI")));
                    }
                    GpiResponse response = new GpiResponse(drug);
                    exchange.getOut().setBody(response);
                }
            });
    }
}

The sql.selectGpi property is read from src/main/resources/application.properties and looks as follows:

sql.selectGpi=select GPI from drugs where ndc = #?dataSource=ds.drugs

The "ds.drugs" reference is to a datasource that's created by Spring. From my AppConfig class:

@Configuration
@PropertySource("classpath:application.properties")
public class AppConfig {

    @Value("${ds.driver.db2}")
    private String jdbcDriverDb2;

    @Value("${ds.password}")
    private String jdbcPassword;

    @Value("${ds.url}")
    private String jdbcUrl;

    @Value("${ds.username}")
    private String jdbcUsername;

    @Bean(name = "ds.drugs")
    public DataSource drugsDataSource() {
        return createDataSource(jdbcDriverDb2, jdbcUsername, jdbcPassword, jdbcUrl);
    }

    private BasicDataSource createDataSource(String driver, String username, String password, String url) {
        BasicDataSource ds = new BasicDataSource();
        ds.setDriverClassName(driver);
        ds.setUsername(username);
        ds.setPassword(password);
        ds.setUrl(url);
        ds.setMaxActive(100);
        ds.setMaxWait(1000);
        ds.setPoolPreparedStatements(true);
        return ds;
    }
}

Unit Testing

The hardest part about unit testing this route was figuring out how to use Camel's testing support. I posted a question to the Camel users mailing list in early June. Based on advice received, I bought Camel in Action, read chapter 6 on testing and went to work. I wanted to eliminate the dependency on a datasource, so I used Camel's AdviceWith feature to modify my route and intercept the SQL call. This allowed me to return pre-defined results and verify everything worked.

@RunWith(CamelSpringJUnit4ClassRunner.class)
@ContextConfiguration(loader = CamelSpringDelegatingTestContextLoader.class, classes = CamelConfig.class)
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
@UseAdviceWith
public class DrugRouteTests {

    @Autowired
    CamelContext camelContext;

    @Produce
    ProducerTemplate template;

    @EndpointInject(uri = "mock:result")
    MockEndpoint result;

    static List<Map> results = new ArrayList<Map>() {{
        add(new HashMap<String, String>() {{
            put("GPI", "123456789");
        }});
    }};

    @Before
    public void before() throws Exception {
        camelContext.setTracing(true);

        ModelCamelContext context = (ModelCamelContext) camelContext;
        RouteDefinition route = context.getRouteDefinition("gpiRequest");
        route.adviceWith(context, new RouteBuilder() {
            @Override
            public void configure() throws Exception {
                interceptSendToEndpoint("sql:*").skipSendToOriginalEndpoint().process(new Processor() {
                    @Override
                    public void process(Exchange exchange) throws Exception {
                        exchange.getOut().setBody(results);
                    }
                });
            }
        });
        route.to(result);
        camelContext.start();
    }

    @Test
    public void testMockSQLEndpoint() throws Exception {
        result.expectedMessageCount(1);
        GpiResponse expectedResult = new GpiResponse(new DrugInfo("123456789"));
        result.allMessages().body().contains(expectedResult);

        GpiRequest request = new GpiRequest();
        request.setNDC("123");
        template.sendBody("direct:gpiRequest", request);

        MockEndpoint.assertIsSatisfied(camelContext);
    }
}

I found AdviceWith to be extremely useful as I developed more routes and tests in this project. I used its weaveById feature to intercept calls to stored procedures, replace steps in my routes and remove steps I didn't want to test. For example, in one route, there was a complicated workflow to interact with a customer's data.

Call a stored procedure in a remote database, which then inserts a record into a temp table.
Lookup that data using the value returned from the stored procedure.
Delete the record from the temp table.
Parse the data (as CSV) since the returned value is ~ delimited.
Convert the parsed data into objects, then do database inserts in a local database (if data doesn't exist).

To make matters worse, remote database access was restricted by IP address. This meant that, while developing, I couldn't even manually test from my local machine. To solve this, I used the following:

interceptSendToEndpoint("bean:*") to intercept the call to my stored procedure bean.
weaveById("myJdbcProcessor").before() to replace the temp table lookup with a CSV file.
Mockito to mock a JdbcTemplate that does the inserts.

To figure out how to configure and execute stored procedures in a route, I used the camel-store-procedure project on GitHub. Mockito's ArgumentCaptor also became very useful when developing a route that called a 3rd-party web service within a route. James Carr has more information on how you might use this to verify values on an argument.

To see if my tests were hitting all aspects of the code, I integrated the cobertura-maven-plugin for code coverage reports (generated by running mvn site).

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <configuration>
                <instrumentation>
                    <excludes>
                        <exclude>**/model/*.class</exclude>
                        <exclude>**/AppInitializer.class</exclude>
                        <exclude>**/StoredProcedureBean.class</exclude>
                        <exclude>**/SoapActionInterceptor.class</exclude>
                    </excludes>
                </instrumentation>
                <check/>
            </configuration>
            <version>2.6</version>
        </plugin>
...
<reporting>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>cobertura-maven-plugin</artifactId>
            <version>2.6</version>
        </plugin>

Integration Testing

Writing an integration test was fairly straightforward. I created a DrugRouteITest class, a client using CXF's JaxWsProxyFactoryBean and called the method on the service.

public class DrugRouteITest {

    private static final String URL = "http://localhost:8080/api/drugs";

    protected static DrugService createCXFClient() {
        JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
        factory.setBindingId("http://schemas.xmlsoap.org/wsdl/soap12/");
        factory.setServiceClass(DrugService.class);
        factory.setAddress(getTestUrl(URL));
        return (DrugService) factory.create();
    }

    @Test
    public void findGpiByNdc() throws Exception {
        // create input parameter
        GpiRequest input = new GpiRequest();
        input.setNDC("54561237201");

        // create the webservice client and send the request
        DrugService client = createCXFClient();
        GpiResponse response = client.findGpiByNdc(input);

        assertEquals("66100525123130", response.getDrugInfo().getGPI());
    }
}

This integration test is only run after Tomcat has started and deployed the app. Unit tests are run by Maven's surefire-plugin, while integration tests are run by the failsafe-plugin. An available Tomcat port is determined by the build-helper-maven-plugin. This port is set as a system property and read by the getTestUrl() method call above.

public static String getTestUrl(String url) {
    if (System.getProperty("tomcat.http.port") != null) {
        url = url.replace("8080", System.getProperty("tomcat.http.port"));
    }
    return url;
}

Below are the relevant bits from pom.xml that determines when to start/stop Tomcat, as well as which tests to run.

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.2</version>
    <configuration>
        <path>/</path>
    </configuration>
    <executions>
        <execution>
            <id>start-tomcat</id>
            <phase>pre-integration-test</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <fork>true</fork>
                <port>${tomcat.http.port}</port>
            </configuration>
        </execution>
        <execution>
            <id>stop-tomcat</id>
            <phase>post-integration-test</phase>
            <goals>
                <goal>shutdown</goal>
            </goals>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.17</version>
    <configuration>
        <excludes>
            <exclude>**/*IT*.java</exclude>
            <exclude>**/Legacy**.java</exclude>
        </excludes>
        <includes>
            <include>**/*Tests.java</include>
            <include>**/*Test.java</include>
        </includes>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.17</version>
    <configuration>
        <includes>
            <include>**/*IT*.java</include>
        </includes>
        <systemProperties>
            <tomcat.http.port>${tomcat.http.port}</tomcat.http.port>
        </systemProperties>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The most useful part of integration testing came when I copied one of my legacy tests into it and started verifying backwards compatibility. Since we wanted to replace existing services, and require no client changes, I had to make the XML request and response match. Charles was very useful for this exercise, letting me inspect the request/response and tweak things to match. The following JAX-WS annotations allowed me to change the XML element names and achieve backward compatibility.

@BindingType(SOAPBinding.SOAP12HTTP_BINDING)
@WebResult(name = "return", targetNamespace = "...")
@ResponseWrapper(localName = "gpiResponse")
@WebParam(name = "args0", targetNamespace = "...")
@XmlElement(name = "...")

Continuous Integration and Deployment

My next item of business was configuring a job in Jenkins to continually test and deploy. Getting all the tests to pass was easy, and deploying to Tomcat was simple enough thanks to the Deploy Plugin and this article. However, after a few deploys, Tomcat would throw OutOfMemory exceptions. Therefore, I ended up creating a second "deploy" job that stops Tomcat, copies the successfully-built WAR to $CATALINA_HOME/webapps, removes $CATALINA_HOME/webapps/ROOT and restarts Tomcat. I used Jenkins "Execute shell" feature to configure these three steps. I was pleased to find my /etc/init.d/tomcat script still worked for starting Tomcat at boot time and providing convenient start/stop commands.

Summary

This article shows you how I implemented and tested a simple Apache Camel route. The route described only does a simple database lookup, but you can see how Camel's testing support allows you to mock results and concentrate on developing your route logic. I found its testing framework very useful and not well documented, so hopefully this article helps to fix that. In the next article, I'll talk about upgrading to Spring 4, integrating Spring Boot and our team's microservice deployment discussions.

Developing Services with Apache Camel - Part I: The Inspiration

Matt Raible — Tue, 23 Sep 2014 10:58:25 -0600

In early May, my client asked me to work on a project migrating from IBM Message Broker 6.1 to an open source solution. Their reason was simple, the IBM solution was end of life and outdated. To prove how out of date it was, the Windows version required Windows XP to run. IBM WebSphere Message Broker has been replaced by IBM Integration Bus in recent years, but no upgrade path existed.

At first, I didn't want to do the project. I was hired as a Modern Java/UI Architect and I had enjoyed my first month upgrading libraries, making recommendations and doing a bit of UI performance work. I hadn't done much with ESBs and I enjoy front-end development a lot more than backend. It took me a couple days to realize they were willing to pay me to learn. That's when I decided to clutch up, learn how to do it all, and get the job done. This article is the first in a series on what I learned during this migration project.

My approach for figuring out how everything worked was similar to working on any new application. I get the source code, install the software necessary to run it, and run it locally so I can interact with it.

Installing IBM Message Broker

The hardest part about installing IBM Message Broker 6.1 was getting the bits to do so. I installed Windows XP in a Parallels VM on my Mac, installed Java 7 and started downloading the install files from my client's server. The files consisted of the following, which I used to install the server, WebSphere Message Broker Toolkit (Eclipse-based), and some plugins we were using.

IBM_Broker_Install_Disks.zip
IBM_plugins.zip
IBM_Upgrade_6.1.06.zip
MessageBrokerInstallFiles.7z

Transferring these files to my laptop took hours over scp. Installing and getting everything to work correctly took days. Much of this time was spent setting up various ODBC data sources, SMTP servers and figuring out how to run a "message flow test" to verify things were working. Before I started working with my client's project, I read Magnus Palmér's article about testing WMB. It was very helpful and I was able to run his project and its tests against my local server.

Choosing an Open Source Solution

When searching for how one might migrate from IBM Message Broker to an open source solution, I stumbled upon this article:

Use an Open Source Broker
Refer to my report for details on Mule ESB and Fuse ESB. If I had to pick right now, I'd use Fuse, as we already use Apache ActiveMQ and Apache CXF, so why not add another Apache-based product? Fuse also has a much higher install base. Mule seems perfectly acceptable, too, though. I would use the simplified routing scheme described in the section above and deploy either Mule or Fuse onto the same server as PFM. Mule/Fuse do not have dependencies on a queue manager like IBM Message Broker does, so there's less overhead. You can also re-use the XSLs from Message Broker.

I think that if you really understood the IBM Message Broker implementation and were comfortable with Active MQ, SOAP, etc... you could have Mule or Fuse implemented in about 2 weeks.

The last sentence inspired me to take a look at Fuse. I knew James Strachan was behind the project, so I shot him an email in early May:

Hey James,

It's been a while - hope you're doing well. I recently started working for a client that has a ton of legacy frameworks and servers. They basically haven't updated anything for 10 years, since the application was originally created by an outsourced company. They're using Acegi 1.0 for crying out loud!
One of the components they have in their system is IBM Message Broker - or maybe it's called WebSphere ESB - I'm not sure. If I succeed in getting it installed, I'm hoping to somehow install the "services" they have configured, which seem to consist of .bar, .esql and .msgflow files. From what I can tell, these seem to be ESB-related, but they might be proprietary as well. I don't have any experience with ESBs, so I'm pretty much fumbling in the dark.
I found the following information online:
https://github.com/cnaphan/osler-mb/blob/master/README.md#alternative-implementations
Under Alternative Implementations:
<quote>
Use an Open Source Broker
...
I think that if you really understood the IBM Message Broker implementation and were comfortable with Active MQ, SOAP, etc... you could have Mule or Fuse implemented in about 2 weeks.
</quote>
Emphasis of the last sentence is mine. So I'm trying to make this happen and migrate from IBM Message Broker to Fuse. I've downloaded JBoss Fuse 6.1, installed it and got it running.
Do you know of any guides or articles about migrating from IBM Message Broker to Fuse?
Thanks,
Matt

James took a couple days to reply, but when he did it was packed with the advice I was hoping for.

I'll ask around to see. TBH the easiest thing really is to just start using Apache Camel for this kinda stuff; its a simple Java library that you can use in any application server. Then make sure you use the hawtio console (which lets you view/edit/trace/debug camel routes in your browser via a nice HTML5 / AngularJS application). http://hawt.io/
JBoss Fuse 6.1 is cool and all though; its based on OSGi which some folks love and some hate. The class loader / application server doesn't really matter to Camel though; use whatever you want (tomcat / jetty / wildfly / karaf / stand alone java applications etc).
Fuse 6.1 is based on a bunch of apache projects plus an upstream open source project called 'fabric8' which deals with provisioning, management, discovery and so forth (i.e. scaling 1 camel route in 1 JVM to many JVMs etc). http://fabric8.io/
The 1.1.x version of fabric8 supports a "Java Container"; i.e. a static flat classpath. For folks who've not done OSGi before (or folks who hate OSGi) I kinda recommend folks not start using OSGi yet - but just start with camel; otherwise it can seem like too much to learn and the OSGi class loading / metadata stuff can kinda get in the way and slow you down. I did a little demo & blog about using 1.1.0.Beta5 of fabric8 (1.1.x of fabric8 will make it into a future JBoss Fuse product release). http://macstrac.blogspot.co.uk/2014/05/micro-services-with-fabric8.html
TL;DR; - play with Apache Camel, it'll solve easily all your integration needs; its got a much bigger & more active community than Mule and unlike Mule - its all open source; there's no locked down, non-open source connectors/magic/tools or proprietary software included. Once you've got your build & tests working fine; ponder which kinda container you wanna use in production (an app server or micro services) - it doesn't matter too much which one. We're working hard on making all our production/testing management/monitoring/diagnostics/debugging tooling work on all containers/app servers anyway (stand alone Java processes via the Java Container, Docker, OSGI (via Karaf like Fuse 6.1), Tomcat, TomEE and Wildfly).
Though if you need 24x7 production support like now, definitely use the JBoss Fuse 6.1 distro If you can wait until later in the year for production support; I'd stick with the fabric8 1.1.x stuff for Java Containers; its simpler & more agile for you go get things sorted.
Here's a little demo of the UI tooling btw https://vimeo.com/album/2635012/video/84674508
It's using the Fuse distro in the demo; but really the hawtio console is doing all the heavy lifting & is available in any JVM thats got a jolokia agent running (and you can use the hawtio Chrome Plugin too). It hopefully will give you a feel for the UI tooling working with camel routes; debugging/tracing them, grokking their metrics and stuff.

After reading James' email, I forwarded it to my client with my recommendation that we start with Apache Camel. He agreed it was a good approach and I went to work.

Development Strategy

On May 21st, I subscribed to the Apache Camel users mailing list and posted my first question the next day. My development strategy was the following:

Write an integration test against the existing service.
Implement the service with Camel, writing unit tests as I progressed.
Copy the logic from step 1's integration test and use it for the new service's integration tests.

I created the project with a Camel Archetype and used Java 7 as the minimum JDK. I decided I wanted no XML in the project (aside from pom.xml) and that I'd use Camel's Java DSL to develop my routes.

Summary

When I first started migrating from IBM Message Broker to an open source solution, I was a bit overwhelmed with the seemingly daunting task. I quickly discovered that Apache Camel was a good replacement and started developing my first route. It took me a couple days to get things working, but I learned a lot in the process - especially around testing. In the next article, I'll talk about how I wrote tests, mocked 3rd party dependencies and configured everything to run in Jenkins. Stay tuned!

Related: I first learned about Apache Camel from Bruce Snyder in 2008 at Colorado Software Summit.

Getting Started with JHipster on OS X

Matt Raible — Mon, 8 Sep 2014 11:30:33 -0600

Last week I was tasked with developing a quick prototype that used AngularJS for its client and Spring MVC for its server. A colleague developed the same application using Backbone.js and Spring MVC. At first, I considered using my boot-ionic project as a starting point. Then I realized I didn't need to develop a native mobile app, but rather a responsive web app.

My colleague mentioned he was going to use RESThub as his starting point, so I figured I'd use JHipster as mine. We allocated a day to get our environments setup with the tools we needed, then timeboxed our first feature spike to four hours.

My first experience with JHipster failed the 10-minute test. I spent a lot of time flailing about with various "npm" and "yo" commands, getting permissions issues along the way. After getting thinks to work with some sudo action, I figured I'd try its Docker development environment. This experience was no better.

JHipster seems like a nice project, so I figured I'd try to find the causes of my issues. This article is designed to save you the pain I had. If you'd rather just see the steps to get up and running quickly, skip to the summary.

The "npm" and "yo" issues I had seemed to be caused by a bad node/npm installation. To fix this, I removed node and installed nvm. Here's the commands I needed to remove node and npm:

sudo rm -rf /usr/local/lib/node_modules
sudo rm -rf /usr/local/include/node
sudo rm /usr/local/bin/node

sudo rm -rf /usr/local/bin/npm
sudo rm /usr/local/share/man/man1/node.1
sudo rm -rf /usr/local/lib/dtrace/node.d
sudo rm -rf ~/.npm

Next, I ran "brew doctor" to make sure Homebrew was still happy. It told me some things were broken:

$ brew doctor
Warning: Broken symlinks were found. Remove them with `brew prune`:
  /usr/local/bin/yo
  /usr/local/bin/ionic
  /usr/local/bin/grunt
  /usr/local/bin/bower

I ran brew update && brew prune, followed by brew install nvm. Next, I added the following to my ~/.profile:

source $(brew --prefix nvm)/nvm.sh

To install the latest version of node, I ran the commands below and set the latest version as the default:

nvm ls-remote
nvm install v0.11.13
nvm alias default v0.11.13

Once I had a fresh version of Node.js, I was able to run JHipster's local installation instructions.

npm install -g yo
npm install -g generator-jhipster

Then I created my project:

yo jhipster

I was disappointed to find this created all the project files in my current directory, rather than in a subdirectory. I'd recommend you do the following instead:

mkdir ~/projectname && cd ~/projectname && yo jhipster

Before creating your project, JHipster asks you a number of questions. To see what they are, see its documentation on creating an application. Two things to be aware of:

Hot reloading Java code doesn't work well (yet) with Java 8
Its OAuth2 implementation doesn't work with WebSockets

In other words, I'd recommend using Java 7 + (cookie-based authentication with websockets) or (oauth2 authentication w/o websockets).

After creating my project, I was able to run it using "mvn spring-boot:run" and view it at http://localhost:8080. To get hot-reloading for the client, I ran "grunt server" and opened my browser to http://localhost:9000.

JHipster + Docker on OS X

I had no luck getting the Docker instructions to work initially. I spent a couple hours on it, then gave up. A couple of days ago, I decided to give it another good ol' college-try. To make sure I figured out everything from scratch, I started by removing Docker.

I re-installed Docker and pulled the JHipster image using the following:

sudo docker pull jdubois/jhipster-docker

The error I got from this was the following:

2014/09/05 19:43:38 Post http:///var/run/docker.sock/images/create?fromImage=jdubois%2Fjhipster-docker&tag=:
dial unix /var/run/docker.sock: no such file or directory

After doing some research, I learned I needed to run boot2docker init first. Next I ran boot2docker up to start the Docker daemon. Then I copied/pasted "export DOCKER_HOST=tcp://192.168.59.103:2375" into my console and tried to run docker pull again.

It failed with the same error. The solution was simpler than you might think: don't use sudo.

$ docker pull jdubois/jhipster-docker
Pulling repository jdubois/jhipster-docker
01bdc74025db: Pulling dependent layers
511136ea3c5a: Download complete
...

The next command that JHipster's documentation recommends is to run the Docker image, forward ports and share folders. When you run it, the terminal seems to hang and trying to ssh into it doesn't work. Others have recently reported a similar issue. I discovered the hanging is caused by a missing "-d" parameter and ssh doesn't work because you need to add a portmap to the VM to expose the port to your host. You can fix this by running the following:

boot2docker down
VBoxManage modifyvm "boot2docker-vm" --natpf1 "containerssh,tcp,,4022,,4022"
VBoxManage modifyvm "boot2docker-vm" --natpf1 "containertomcat,tcp,,8080,,8080"
VBoxManage modifyvm "boot2docker-vm" --natpf1 "containergruntserver,tcp,,9000,,9000"
VBoxManage modifyvm "boot2docker-vm" --natpf1 "containergruntreload,tcp,,35729,,35729"
boot2docker start

After making these changes, I was able to start the image and ssh into it.

docker run -d -v ~/jhipster:/jhipster -p 8080:8080 -p 9000:9000 -p 35729:35729 -p 4022:22 -t jdubois/jhipster-docker
ssh -p 4022 jhipster@localhost

I tried creating a new project within the VM (cd /jhipster && yo jhipster), but it failed with the following error:

/usr/lib/node_modules/generator-jhipster/node_modules/yeoman-generator/node_modules/mkdirp/index.js:89
                    throw err0;
                          ^
Error: EACCES, permission denied '/jhipster/src'

The fix was giving the "jhipster" user ownership of the directory.

sudo chown jhipster /jhipster

After doing this, I was able to generate an app and run it using "mvn spring-boot:run" and access it from my Mac at http://localhost:8080. I was also able to run "grunt server" and see it at http://localhost:9000

However, I was puzzled to see that there was nothing in my ~/jhipster directory. After doing some searching, I found that the docker run -v /host/path:/container/path doesn't work on OS X.

David Gageot's A Better Boot2Docker on OSX led me to svendowideit/samba, which solved this problem. The specifics are documented in boot2docker's folder sharing section.

I shutdown my docker container by running "docker ps", grabbing the first two characters of the id and then running:

docker stop [2chars]

I started the JHipster container without the -v parameter, used "docker ps" to find its name (backstabbing_galileo in this case), then used that to add samba support.

docker run -d -p 8080:8080 -p 9000:9000 -p 35729:35729 -p 4022:22 -t jdubois/jhipster-docker
docker run --rm -v /usr/local/bin/docker:/docker -v /var/run/docker.sock:/docker.sock svendowideit/samba backstabbing_galileo

Then I was able to connect using Finder > Go > Connect to Server, using the following for the server address:

cifs://192.168.59.103/jhipster

To make this volume appear in my regular development area, I created a symlink:

ln -s /Volumes/jhipster ~/dev/jhipster

After doing this, all the files were marked as read-only. To fix, I ran "chmod -R 777 ." in the directory on the server. I noticed that this also worked if I ran it from my Mac's terminal, but it took quite a while to traverse all the files. I noticed a similar delay when loading the project into IntelliJ.

Summary

Phew! That's a lot of information that can be condensed down into four JHipster + Docker on OS X tips.

Make sure your npm installation doesn't require sudo rights. If it does, reinstall using nvm.
Add portmaps to your VM to expose ports 4022, 8080, 9000 and 35729 to your host.
Change ownership on the /jhipster in the Docker image: sudo chown jhipster /jhipster.
Use svendowideit/samba to share your VM's directories with OS X.

Why I prefer IntelliJ IDEA over Eclipse

Matt Raible — Mon, 21 Jul 2014 13:33:55 -0600

Over the last couple months, I've received a few emails asking why I prefer IntelliJ IDEA over Eclipse. They usually go something like this:

I keep seeing you recommending IntelliJ. I keep trying it intermittently with using Eclipse, but I feel like I'm missing something obvious that makes so many people think it's better. Granted having the usual plugins incorporated is nice, but other things like the build process and debugger sometimes seems a step back from Eclipse. Could you please blog a '10 reasons why I love IntelliJ' or point me to something that would clue me in?

I grew to love IntelliJ for a few reasons. It all started in 2006 when I decided to migrate AppFuse from Ant to Maven. Before that, I was a huge Eclipse fan (2002 - 2006). Before Eclipse, I used HomeSite, an HTML Editor to write all my Java code (1999-2002). Eclipse was the first IDE that didn't hog all my system's memory and was pleasant to work with.

The reason I started using IntelliJ in 2006 was because of it's multi-module Maven support. Eclipse's Maven support was terrible, and m2e hasn't gotten a whole lot better in recent years AFAIK.

Back then, I used to think everything should be built and run from the command line. A couple years later, I realized it was better to run tests and debug from an IDE. Now I'm more concerned with the ability to run tests and debug in an IDE than I am from the build system.

In 2009, I started doing a lot more front-end work: writing HTML, CSS and JavaScript. I also started digging into alternate languages for these: Jade, GWT, CoffeeScript, LESS, SASS - even Scala. I found IntelliJ's support, and plugins, to be outstanding for these languages and really enjoyed how it would tell me I had invalid JavaScript, HTML and CSS.

My original passion in software was HTML and JavaScript and I found that hasn't changed in the last 15 years. AFAIK, Eclipse still has terrible web tools support; it excels at Java (and possibly C++ support). Even today, I write most of my HTML code (for InfoQ and this blog) in IntelliJ.

In reality, it probably doesn't matter which IDE you use, as long as you're productive with it. Once you learn one IDE well, the way others do things will likely seem backwards. I'm so familiar with debugging in IntelliJ, that when I tried to use Eclipse's debugger a few weeks ago, it seemed backwards to me.

In a nutshell: the technologies I've worked with have been better embraced by IntelliJ. Has this happened to you? Have certain technologies caused you to use one IDE over another?

How do you stay current with emerging technologies?

Matt Raible — Wed, 28 May 2014 10:48:38 -0600

I recently received an email from a former co-worker. She was curious to know what I read/do to know what it is "trending" in the software world. I think this is good knowledge to share, and I'm also interested in what others do to keep up. Here's my response to her:

My technique for staying up-to-date is mostly reading, and attending some user group meetings. For reading, I read news.ycombinator.com, as well as infoq.com - who I now write for. DZone.com (esp. Javalobby and its HTML5 Zone) is also pretty good, as is arstechnica.com. I don't read nearly as much as I used to when I was subscribed to all of their RSS feeds and read them religiously.

Nowadays, most of my information comes from Twitter. I follow people that are involved in technologies I'm interested in. I try to keep the number of people I follow to 50 as I don't want to spend too much time reading tweets.

For meetups, most are on meetup.com these days. I'd find a couple that have technologies you're interested in (e.g. a local HTML5 meetup or Java user group) and join the group. You'll get email notifications when they have meetings.

Other than that, sometimes I do "conference driven learning". I'll pick a few technologies I'm interested in learning, submit a talk to a conference or user group, then be forced to learn and present on them when it gets accepted. It can be stressful, but it works and usually results in a good presentation because I can share the experience of learning.

One interesting thing I've realized about Twitter is I can make technologies seem "hot" based on the people I follow. If I'm following a bunch of AngularJS folks, my feed is filled with Angular-related tweets and it seems like the hottest technology ever. If I tweak who I follow to have a bunch of Groovy enthusiasts, or Scala folks, the same thing happens.

Of course, the best way to learn new technologies is to use them in your daily job. I strive to do this with my clients, but it doesn't always work out. I've found that working on open source projects and speaking at conferences can help you learn if you're in a stagnant environment. Then again, if you're not happy at work, quit.

What do you do to stay on top of emerging trends in technology?

First Devoxx4Kids in Denver a Wild Success!

Matt Raible — Mon, 5 May 2014 23:42:30 -0600

The first Devoxx4Kids Denver was a wild success! This last Saturday, 20 enthusiastic Minecraft hackers gathered at Thrive in Cherry Creek to learn from one of the best. With masterful skill, Scott Davis, founder of ThirstyHead.com, taught everyone how to get a development environment setup, run a local Minecraft server and install plugins into it. You can see the materials we used for this class on Scott's site, at Introduction to Server-side Minecraft Programming.

McGinity Photo was kind enough to snap a bunch of pictures, which you can find on Flickr. A sampling is below:

I can't thank Thrive enough for their awesome venue. They had coffee ready and the front door wide-open when we arrived at 9am. The class started at 10am, and students started streaming in around 9:30. It was a mad scramble at first to copy all the setup files to student computers. Heck, it was a mad scramble for me most of the class: configuring environments, showing kids how to use the command line, troubleshooting errors -- all while the A/C was off. By the end of the class, the students were humming, connecting to each other's laptops and customizing their own worlds.

The only thing I regret is not setting up the students' laptops ahead of time. It would've been nice if Java and Gradle were installed and students could just run commands. However, I think it's neat they learned how to install and configure their own Java development environment. In the future, I'll send out instructions for parents a week before. For those needing help, we'll offer an "early setup" session the morning of the class. It'd also be nice to have a couple extra laptops for those that are too slow.

For the next meeting, it'd be cool to use Java since everyone has it all setup. Maybe we could control some robots with code or dive even deeper into hacking Minecraft. Whatever it is, it's sure to be fun!

Update: One other issue I forgot to mention. My kids have been sharing a Minecraft account for the last year. During the class, we found the duplicate username didn't work when they both wanted to join a server. It took 18 hours to get an additional account from Minecraft.net (6 hours for activation email, 12 for the unique username chooser to work). Make sure all kids have their own username before you teach a class like this.

Devoxx4Kids - Denver Chapter Begins!

Matt Raible — Tue, 8 Apr 2014 10:59:29 -0600

I'm happy to announce the first meeting of the Denver Chapter of Devoxx4Kids is now open for registration. It's a two hour class titled Introduction to Server-Side Minecraft Programming and will be taught by Denver's own Scott Davis. The class will be held on May 3rd, from 10am - 12pm at Thrive's Cherry Creek location, where we can comfortably fit 20 students. Cost is $10, but you'll get that back in the form of a t-shirt. Age requirement is 9-18 and kids should have basic computer skills (copy/paste, opening applications, etc.). Minecraft experience will certainly help too.

I'd like to thank Daniel De Luca for his initial assistance with getting Devoxx4Kids setup in Denver and Arun Gupta for starting Devoxx4Kids USA. Arun has been a great help in getting things going and answering my questions over the last few months. Of course, none of it would be happening without Scott Davis or Thrive. If you join us on May 3rd, you'll see that Scott is an awesome teacher and Thrive has some incredible facilities.

My initial goal with Devoxx4Kids in Denver is to host a class or two this year. If there's enough demand, we can expand. For now, we're starting small and seeing where it takes us. If you're interested in teaching a future class, please let me know. We'd love to teach the kids a number of skills, from Scratch to NAO Humanoid Robot programming to building things with Arduino and Raspberry Pi.

Documenting your Spring API with Swagger

Matt Raible — Tue, 25 Mar 2014 13:07:18 -0600

Over the last several months, I've been developing a REST API using Spring Boot. My client hired an outside company to develop a native iOS app, and my development team was responsible for developing its API. Our main task involved integrating with Epic, a popular software system used in Health care. We also developed a Crowd-backed authentication system, based loosely on Philip Sorst's Angular REST Security.

To document our API, we used Spring MVC integration for Swagger (a.k.a. swagger-springmvc). I briefly looked into swagger4spring-web, but gave up quickly when it didn't recognize Spring's @RestController. We started with swagger-springmvc 0.6.5 and found it fairly easy to integrate. Unfortunately, it didn't allow us to annotate our model objects and tell clients which fields were required. We were quite pleased when a new version (0.8.2) was released that supports Swagger 1.3 and its @ApiModelProperty.

What is Swagger?
The goal of Swagger is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

To demonstrate how Swagger works, I integrated it into Josh Long's x-auth-security project. If you have a Boot-powered project, you should be able to use the same steps.

1. Add swagger-springmvc dependency to your project.

<dependency>
    <groupId>com.mangofactory</groupId>
    <artifactId>swagger-springmvc</artifactId>
    <version>0.8.2</version>
</dependency>

Note: on my client's project, we had to exclude "org.slf4j:slf4j-log4j12" and add "jackson-module-scala_2.10:2.3.1" as a dependency. I did not need to do either of these in this project.

2. Add a SwaggerConfig class to configure Swagger.

The swagger-springmvc documentation has an example of this with a bit more XML.

package example.config;

import com.mangofactory.swagger.configuration.JacksonScalaSupport;
import com.mangofactory.swagger.configuration.SpringSwaggerConfig;
import com.mangofactory.swagger.configuration.SpringSwaggerModelConfig;
import com.mangofactory.swagger.configuration.SwaggerGlobalSettings;
import com.mangofactory.swagger.core.DefaultSwaggerPathProvider;
import com.mangofactory.swagger.core.SwaggerApiResourceListing;
import com.mangofactory.swagger.core.SwaggerPathProvider;
import com.mangofactory.swagger.scanners.ApiListingReferenceScanner;
import com.wordnik.swagger.model.*;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import static com.google.common.collect.Lists.newArrayList;

@Configuration
@ComponentScan(basePackages = "com.mangofactory.swagger")
public class SwaggerConfig {

    public static final List<String> DEFAULT_INCLUDE_PATTERNS = Arrays.asList("/news/.*");
    public static final String SWAGGER_GROUP = "mobile-api";

    @Value("${app.docs}")
    private String docsLocation;

    @Autowired
    private SpringSwaggerConfig springSwaggerConfig;
    @Autowired
    private SpringSwaggerModelConfig springSwaggerModelConfig;

    /**
     * Adds the jackson scala module to the MappingJackson2HttpMessageConverter registered with spring
     * Swagger core models are scala so we need to be able to convert to JSON
     * Also registers some custom serializers needed to transform swagger models to swagger-ui required json format
     */
    @Bean
    public JacksonScalaSupport jacksonScalaSupport() {
        JacksonScalaSupport jacksonScalaSupport = new JacksonScalaSupport();
        //Set to false to disable
        jacksonScalaSupport.setRegisterScalaModule(true);
        return jacksonScalaSupport;
    }


    /**
     * Global swagger settings
     */
    @Bean
    public SwaggerGlobalSettings swaggerGlobalSettings() {
        SwaggerGlobalSettings swaggerGlobalSettings = new SwaggerGlobalSettings();
        swaggerGlobalSettings.setGlobalResponseMessages(springSwaggerConfig.defaultResponseMessages());
        swaggerGlobalSettings.setIgnorableParameterTypes(springSwaggerConfig.defaultIgnorableParameterTypes());
        swaggerGlobalSettings.setParameterDataTypes(springSwaggerModelConfig.defaultParameterDataTypes());
        return swaggerGlobalSettings;
    }

    /**
     * API Info as it appears on the swagger-ui page
     */
    private ApiInfo apiInfo() {
        ApiInfo apiInfo = new ApiInfo(
                "News API",
                "Mobile applications and beyond!",
                "https://helloreverb.com/terms/",
                "matt@raibledesigns.com",
                "Apache 2.0",
                "http://www.apache.org/licenses/LICENSE-2.0.html"
        );
        return apiInfo;
    }

    /**
     * Configure a SwaggerApiResourceListing for each swagger instance within your app. e.g. 1. private  2. external apis
     * Required to be a spring bean as spring will call the postConstruct method to bootstrap swagger scanning.
     *
     * @return
     */
    @Bean
    public SwaggerApiResourceListing swaggerApiResourceListing() {
        //The group name is important and should match the group set on ApiListingReferenceScanner
        //Note that swaggerCache() is by DefaultSwaggerController to serve the swagger json
        SwaggerApiResourceListing swaggerApiResourceListing = new SwaggerApiResourceListing(springSwaggerConfig.swaggerCache(), SWAGGER_GROUP);

        //Set the required swagger settings
        swaggerApiResourceListing.setSwaggerGlobalSettings(swaggerGlobalSettings());

        //Use a custom path provider or springSwaggerConfig.defaultSwaggerPathProvider()
        swaggerApiResourceListing.setSwaggerPathProvider(apiPathProvider());

        //Supply the API Info as it should appear on swagger-ui web page
        swaggerApiResourceListing.setApiInfo(apiInfo());

        //Global authorization - see the swagger documentation
        swaggerApiResourceListing.setAuthorizationTypes(authorizationTypes());

        //Every SwaggerApiResourceListing needs an ApiListingReferenceScanner to scan the spring request mappings
        swaggerApiResourceListing.setApiListingReferenceScanner(apiListingReferenceScanner());
        return swaggerApiResourceListing;
    }

    @Bean
    /**
     * The ApiListingReferenceScanner does most of the work.
     * Scans the appropriate spring RequestMappingHandlerMappings
     * Applies the correct absolute paths to the generated swagger resources
     */
    public ApiListingReferenceScanner apiListingReferenceScanner() {
        ApiListingReferenceScanner apiListingReferenceScanner = new ApiListingReferenceScanner();

        //Picks up all of the registered spring RequestMappingHandlerMappings for scanning
        apiListingReferenceScanner.setRequestMappingHandlerMapping(springSwaggerConfig.swaggerRequestMappingHandlerMappings());

        //Excludes any controllers with the supplied annotations
        apiListingReferenceScanner.setExcludeAnnotations(springSwaggerConfig.defaultExcludeAnnotations());

        //
        apiListingReferenceScanner.setResourceGroupingStrategy(springSwaggerConfig.defaultResourceGroupingStrategy());

        //Path provider used to generate the appropriate uri's
        apiListingReferenceScanner.setSwaggerPathProvider(apiPathProvider());

        //Must match the swagger group set on the SwaggerApiResourceListing
        apiListingReferenceScanner.setSwaggerGroup(SWAGGER_GROUP);

        //Only include paths that match the supplied regular expressions
        apiListingReferenceScanner.setIncludePatterns(DEFAULT_INCLUDE_PATTERNS);

        return apiListingReferenceScanner;
    }

    /**
     * Example of a custom path provider
     */
    @Bean
    public ApiPathProvider apiPathProvider() {
        ApiPathProvider apiPathProvider = new ApiPathProvider(docsLocation);
        apiPathProvider.setDefaultSwaggerPathProvider(springSwaggerConfig.defaultSwaggerPathProvider());
        return apiPathProvider;
    }


    private List<AuthorizationType> authorizationTypes() {
        ArrayList<AuthorizationType> authorizationTypes = new ArrayList<>();

        List<AuthorizationScope> authorizationScopeList = newArrayList();
        authorizationScopeList.add(new AuthorizationScope("global", "access all"));

        List<GrantType> grantTypes = newArrayList();

        LoginEndpoint loginEndpoint = new LoginEndpoint(apiPathProvider().getAppBasePath() + "/user/authenticate");
        grantTypes.add(new ImplicitGrant(loginEndpoint, "access_token"));

        return authorizationTypes;
    }

    @Bean
    public SwaggerPathProvider relativeSwaggerPathProvider() {
        return new ApiRelativeSwaggerPathProvider();
    }

    private class ApiRelativeSwaggerPathProvider extends DefaultSwaggerPathProvider {
        @Override
        public String getAppBasePath() {
            return "/";
        }

        @Override
        public String getSwaggerDocumentationBasePath() {
            return "/api-docs";
        }
    }
}

The ApiPathProvider class referenced above is as follows:

package example.config;

import com.mangofactory.swagger.core.SwaggerPathProvider;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.util.UriComponentsBuilder;

import javax.servlet.ServletContext;

public class ApiPathProvider implements SwaggerPathProvider {
    private SwaggerPathProvider defaultSwaggerPathProvider;
    @Autowired
    private ServletContext servletContext;

    private String docsLocation;

    public ApiPathProvider(String docsLocation) {
        this.docsLocation = docsLocation;
    }

    @Override
    public String getApiResourcePrefix() {
        return defaultSwaggerPathProvider.getApiResourcePrefix();
    }

    public String getAppBasePath() {
        return UriComponentsBuilder
                .fromHttpUrl(docsLocation)
                .path(servletContext.getContextPath())
                .build()
                .toString();
    }

    @Override
    public String getSwaggerDocumentationBasePath() {
        return UriComponentsBuilder
                .fromHttpUrl(getAppBasePath())
                .pathSegment("api-docs/")
                .build()
                .toString();
    }

    @Override
    public String getRequestMappingEndpoint(String requestMappingPattern) {
        return defaultSwaggerPathProvider.getRequestMappingEndpoint(requestMappingPattern);
    }

    public void setDefaultSwaggerPathProvider(SwaggerPathProvider defaultSwaggerPathProvider) {
        this.defaultSwaggerPathProvider = defaultSwaggerPathProvider;
    }
}

In src/main/resources/application.properties, add an "app.docs" property. This will need to be changed as you move your application from local -> test -> staging -> production. Spring Boot's externalized configuration makes this fairly simple.

app.docs=http://localhost:8080

3. Verify Swagger produces JSON.

After completing the above steps, you should be able to see the JSON Swagger generates for your API. Open http://localhost:8080/api-docs in your browser or curl http://localhost:8080/api-docs.

{
    "apiVersion": "1",
    "swaggerVersion": "1.2",
    "apis": [
        {
            "path": "http://localhost:8080/api-docs/mobile-api/example_NewsController",
            "description": "example.NewsController"
        }
    ],
    "info": {
        "title": "News API",
        "description": "Mobile applications and beyond!",
        "termsOfServiceUrl": "https://helloreverb.com/terms/",
        "contact": "matt@raibledesigns.com",
        "license": "Apache 2.0",
        "licenseUrl": "http://www.apache.org/licenses/LICENSE-2.0.html"
    }
}

4. Copy Swagger UI into your project.

Swagger UI is a good-looking JavaScript client for Swagger's JSON. I integrated it using the following steps:

git clone https://github.com/wordnik/swagger-ui
cp -r swagger-ui/dist ~/dev/x-auth-security/src/main/resources/public/docs

I modified docs/index.html, deleting its header (<div id='header'>) element, as well as made its url dynamic.

...
$(function () {
  var apiUrl = window.location.protocol + "//" + window.location.host;
  if (window.location.pathname.indexOf('/api') > 0) {
    apiUrl += window.location.pathname.substring(0, window.location.pathname.indexOf('/api'))
  }
  apiUrl += "/api-docs";
  log('API URL: ' + apiUrl);
  window.swaggerUi = new SwaggerUi({
    url: apiUrl,
    dom_id: "swagger-ui-container",
...

After making these changes, I was able to open fire up the app with "mvn spring-boot:run" and view http://localhost:8080/docs/index.html in my browser.

5. Annotate your API.

There are two services in x-auth-security: one for authentication and one for news. To provide more information to the "news" service's documentation, add @Api and @ApiOperation annotations. These annotations aren't necessary to get a service to show up in Swagger UI, but if you don't specify the @Api("user"), you'll end up with an ugly-looking class name instead (e.g. example_xauth_UserXAuthTokenController).

@RestController
@Api(value = "news", description = "News API")
class NewsController {

    Map<Long, NewsEntry> entries = new ConcurrentHashMap<Long, NewsEntry>();

    @RequestMapping(value = "/news", method = RequestMethod.GET)
    @ApiOperation(value = "Get News", notes = "Returns news items")
    Collection<NewsEntry> entries() {
        return this.entries.values();
    }

    @RequestMapping(value = "/news/{id}", method = RequestMethod.DELETE)
    @ApiOperation(value = "Delete News item", notes = "Deletes news item by id")
    NewsEntry remove(@PathVariable Long id) {
        return this.entries.remove(id);
    }

    @RequestMapping(value = "/news/{id}", method = RequestMethod.GET)
    @ApiOperation(value = "Get a news item", notes = "Returns a news item")
    NewsEntry entry(@PathVariable Long id) {
        return this.entries.get(id);
    }

    @RequestMapping(value = "/news/{id}", method = RequestMethod.POST)
    @ApiOperation(value = "Update News", notes = "Updates a news item")
    NewsEntry update(@RequestBody NewsEntry news) {
        this.entries.put(news.getId(), news);
        return news;
    }
...
}

You might notice the screenshot above only shows news. This is because SwaggerConfig.DEFAULT_INCLUDE_PATTERNS only specifies news. The following will include all APIs.

public static final List<String> DEFAULT_INCLUDE_PATTERNS = Arrays.asList("/.*");

After adding these annotations and modifying SwaggerConfig, you should see all available services.

In swagger-springmvc 0.8.x, the ability to use @ApiModel and @ApiModelProperty annotations was added. This means you can annotate NewsEntry to specify which fields are required.

@ApiModel("News Entry")
public static class NewsEntry {
    @ApiModelProperty(value = "the id of the item", required = true)
    private long id;
    @ApiModelProperty(value = "content", required = true)
    private String content;

    // getters and setters
}

This results in the model's documentation showing up in Swagger UI. If "required" isn't specified, a property shows up as optional.

Parting Thoughts
The QA Engineers and 3rd Party iOS Developers have been very pleased with our API documentation. I believe this is largely due to Swagger and its nice-looking UI. The Swagger UI also provides an interface to test the endpoints by entering parameters (or JSON) into HTML forms and clicking buttons. This could benefit those QA folks that prefer using Selenium to test HTML (vs. raw REST endpoints).

I've been quite pleased with swagger-springmvc, so kudos to its developers. They've been very responsive in fixing issues I've reported. The only thing I'd like is support for recognizing JSR303 annotations (e.g. @NotNull) as required fields.

To see everything running locally, checkout my modified x-auth-security project on GitHub and the associated commits for this article.