Raible Designs

My Marvelous Road Trip to the Utah JUG

2024-05-22T09:35:09-06:00

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

2024-05-11T10:27:21-06:00

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 Angular Mini-Book 3.0 is now available!

2023-06-23T05:44:05-06:00

I'm excited to announce that the Angular Mini-Book 3.0 is now available! You can download it in PDF and EPUB formats from InfoQ.

About this book

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy. What about deploying your Angular app to the cloud? Yep, it covers that too!

What's new?

This new edition uses Angular 15 and Spring Boot 3.0. Some other fun facts:

Tech reviewed by Angular expert Alisa Duncan. She improved many of the code samples, and I'm grateful for her help. You should follow her on Twitter!
First commit on 3.0 version: Feb 16, 2023
Files changed since 2.0: 558
Build date: June 9, 2023

You might say this book is outdated on launch. However, I created a GitHub Action to upgrade all the examples to use Angular 16 and Spring Boot 3.1. This action proves all the code should work if you create apps with the latest Angular and Spring Boot versions. 😊

To send us feedback or issues, e-mail InfoQ at feedback@infoq.com, email me at matt@raibledesigns.com, or hit me up on Twitter @mraible.

The Angular Mini-Book 2.0 is now available!

2022-02-18T08:24:39-07:00

I'm pumped to announce that the Angular Mini-Book 2.0 has been released! You can download it in PDF and EPUB formats from InfoQ.

About this book

What's new?

This new edition (2.0) uses Angular 13 and Spring Boot 2.6. Some other fun facts:

First commit on 2.0 version: Nov 19, 2021 { Thanks to James Ward for his help upgrading to Knative 1.0! }
Upgraded the book's project to use Gradle 7: Dec 2, 2021 { I appreciate you Guillaume Grossetie! }
Upgraded to Angular 13 and Spring Boot 2.6.1: Jan 7, 2022
Detailed QA of all the code: Jan 27 - Feb 10, 2022
Files changed since 1.0: 244
Build date: Feb 17, 2022

For more information about this book, please read my post about its 1.0 release.

To send us feedback or issues, e-mail InfoQ at feedback@infoq.com, email me at matt@raibledesigns.com, or hit me up on Twitter @mraible.

The Angular Mini-Book 1.0 is now available!

2021-11-17T14:48:40-07:00

I'm pleased to announce that the Angular Mini-Book has been released! You can download it in PDF and EPUB formats from InfoQ.

About this book

The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication. Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

This initial edition (v1.0) uses Angular 12 and Spring Boot 2.5. I do plan on updating it for Angular 13 and Spring Boot 2.6. If you have any tips for upgrading, please let me know!

Purpose of the book

I think building web and mobile applications with Angular, Bootstrap, and Spring Boot is a great experience. I'd like to encourage more developers to try it.

Thanks!

I'm incredibly grateful to Trish, Abbie, and Jack. They put up with my late nights and extended screen time while I worked on this book.

To Miško Hevery, thank you for inventing Angular and changing the lives of frontend developers. To the whole Angular team, I appreciate you and all you do for the community. Kudos for making our apps faster with every release!

To Phil Webb and Dave Syer, thanks for creating Spring Boot and simplifying Java for everyone. Hats off to the whole Spring team for their tireless dedication to quality open source projects.

I want to thank this book's tech editor, Deepu K Sasidharan. I looked to him for his deep experience with both TypeScript and JavaScript. Many sections are more streamlined because of his advice.

This book's copy editor, Maureen Spencer, helped correct my grammar and make this book easier on the eyes. I'm thankful for your help, Maureen.

David Neal created the cover image and all of the illustrations. He's awesome! You should consider buying his stuff and follow him for his dad jokes.

Finally, my compliments to you, potential reader. It's a heckuva time to be writing code. Enjoy your learning adventures! 😃

Fun facts

Creating this book was more difficult than I imagined. As you can see from the timeline below, I didn't do a whole lot in 2020. I ramped things up this spring and tried to get 'er done before Angular 13 and Spring Boot 2.6 were released. At the very least, I succeeded on the second goal, even if only by a couple days.

First commit: June 25, 2020
Outline created: September 15, 2020
Started writing: October 3, 2020
Upgraded to Angular 12 and Spring Boot 2.4.1: May 4, 2021
Finished first draft: June 30, 2021
Build date: November 16, 2021
Total commits: 108

This book was authored with Asciidoctor and I appreciate the assistance I received from Guillaume Grossetie.

The source code repo contains all the demos in addition to the book's code. The Count Lines of Code report (excluding generated files and directories) shows that it's mostly words, followed by example code:

--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
AsciiDoc                         14           1651             20           5312
HTML                             38            211              0           2349
TypeScript                       86            322            299           2057
JSON                             27              0              0           1346
CSS                              11            265            250           1288
YAML                             10              8             89            654
Kotlin                           18             87              4            499
JavaScript                       12             35             48            355
Gradle                            6             43              4            227
Bourne Shell                      2             50            144            225

I'm proud to have built the v1.0 version of the book on my parent's 49th anniversary. Happy Anniversary Mom and Dad!! 🥳

To send us feedback or issues, e-mail InfoQ at feedback@infoq.com, email me at matt@raibledesigns.com, or hit me up on Twitter @mraible.

Secure by Design Book Review

2020-05-25T20:11:22-06:00

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

2020-03-15T14:24:25-06:00

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.

A Beautiful Adventure to JBCNConf, Barcelona, and Boston

2019-06-29T09:33:15-06:00

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

2019-05-02T09:54:15-06:00

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.

Life as an Open Source Developer, One Year Later

2017-11-06T08:33:17-07:00

It's been a little over a year since I wrote about life as an open source developer. I'm happy to say I still haven't written a single line of proprietary code. Of course, things have changed a lot in the last year. I thought going full-time would bring stability to my career. Instead, six months into it we joined forces with Okta.

The transition was rough at first. At Stormpath, we had full-featured SDKs and a great relationship with developers that used our service. We were able to port many of our SDKs to work with Okta, but we discovered that Okta didn't have a great relationship with developers. In fact, their developer blog hadn't been updated in over a year when we arrived.

On the upside, Okta's API supported standards like SAML, OAuth, and OpenID Connect. Open standards made it possible to use other frameworks and not have to rely on our own. I was pumped to find that Spring Security made it easy to integrate with SAML and OAuth. In fact, I was able to leverage these standards to add OIDC support to JHipster.

Okta's new developer console and open pricing are just a couple examples of improved happenings since we arrived. The Okta Spring Boot Starter and JavaScript libraries for Node.js, Angular, and React are also pretty awesome.

I'm happy to say my contributions on GitHub almost doubled in the last year!

As far as stress is concerned, that hasn't changed much. I've learned that the stress I feel from work is still causing me to have high blood pressure. When I measure it in the mornings, or at night, it's fine. When I measure it during the day, it's elevated. I believe my high blood pressure is caused by doing too much. Sure, it's great to be productive and accomplish a lot for my company, but it's killing me.

Therein lies the rub. I get to create my job. All I'm asked to do is write a blog post per week and speak at a conference (or meetup) once a month. Yet I'm doing way more than that. Since this time last year, I've delivered 33 presentations, in 13 different cities. I keep a page on this blog updated with all my presentations.

Next year, I still plan to speak a lot, but I plan on toning things down a bit. I'll be concentrating on US cities, with large Java user groups, and I'll be limiting my travel overseas.

Outside of my health concerns, I'm still loving my job. The fact that I get paid to speak at great conferences, write example applications, and discover new ways to do things is awesome. It's also pretty sweet that I was able to update the JHipster Mini-Book and upgrade 21-Points Health during work hours. The fact that I got featured on the main Okta blog was pretty cool too.

The good news is my overseas travel isn't done this year. Today, I leave for Devoxx Belgium, one of my favorite conferences. It'll be my first time in Antwerp without Trish. However, I'm speaking with friends Josh Long and Deepu Sasidharan, so it's sure to be a good time. Traveling to Devoxx Morocco should be fun too. I've never been to Casablanca before.

In December, you can catch me at SpringOne and The Rich Web Experience. Next year, I'll be speaking at Denver Microservices meetup, Utah JUG, Seattle JUG, and JazzCon. I plan to do a JUG tour in the northeast US too.

You might've noticed I don't write a lot of technical content here anymore. That's because I'm doing most of my writing on developer.okta.com/blog. I'm still writing for InfoQ as well. I really enjoyed attending the JavaOne keynotes and writing up what I saw.

I'll leave you with this, a project I'm working on actively and plan to finish before Devoxx Morocco.

Had a good hacking session today w/ @java_hipster & @Ionicframework. Creating a JHipster-enabled Ionic client works! https://t.co/5biHQDO941
— Matt Raible (@mraible) November 3, 2017

Viva la Open Source!

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

2017-05-24T09:50:55-06:00

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

2017-04-10T11:53:42-06:00

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!

Life as an Open Source Developer

2016-11-03T16:29:01-06:00

It's been a little over a month since I started my new gig at Stormpath. I gotta say, life is great as an open source developer! Yes, I did start working for them as a consultant in April, so it's not a huge change for me. However, I only recently realized I haven't written a single line of proprietary code the entire time. My GitHub contributions look pretty good this year. They're nothing like @mojavelinux, or @dsyer, but I'll get there.

It's also been a bit more stress than I'm used to. I think this comes from a couple things: 1) turning my hobby into my job and 2) I've set a lot of high expectations for myself. As a developer evangelist, I get to create my own job. That means I can speak at the conferences I want to, write the code I want to, create the blog posts I want to, and everything else in between.

At the end of September, I finished updating the JHipster Mini-Book for JHipster 3.x. It's gone through tech editing and it's being copy-edited right now. I hope to release it within a week.

In early October, I said I'd commit to writing one blog post per week, develop a JHipster module for Stormpath, and help get their Angular 2 support good enough for an alpha release. I'm happy to report I've been able to accomplish most of these and I hope to show off our Angular 2 support soon.

I then channeled my efforts into integrating Stormpath's Java SDK with their AngularJS directives. You can read about how I did that in Get Started with AngularJS, Spring Boot, and Stormpath. Unlike my previous AngularJS tutorial, this one connects to a backend and shows how to communicate with Spring Boot cross-domain.

If you like to read code more than words, you can look at the example project's commits on GitHub.

Create an AngularJS UI: search and edit features
Create a Spring Boot app with Stormpath: app from start.stormpath.io
Develop an API to CRUD people with Spring Data REST: /api/people
Integrate AngularJS and Spring Boot apps: cross-domain
Integrate Stormpath into AngularJS for login, registration and forgot password: Stormpath Angular SDK

Last week, I released a JHipster module that integrates Stormpath. This exercise was good because I was able to identify some gaps in Stormpath's SDKs and fix them. Getting something to work made me feel good; having the ability to improve the developer experience was even better! Of course, I blogged about what I learned.

This week, I edited and code reviewed some posts from Karl Penzhorn on React with Spring Boot and using webpack with React. I also got to bang my head against the wall writing Angular 2 tests. If you're writing a module for Angular 2, generator-angular2-module provides a nice starting point.

Last, but certainly not least, I'll be speaking at a few events about Microservices, JHipster, Angular 2 and Stormpath in the near feature.

Rocky Mountain Software Symposium, November 19
The Rich Web Experience, December 9
A joint talk at Denver JUG with the infamous Josh Long, December 14

If you have any questions about developer evangelism, the technologies I mentioned in this post, or Stormpath, please let me know. Otherwise, I hope to see you on the road soon!

Moving AppFuse into the Attic

2016-04-28T15:40:16-06:00

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

2016-04-26T07:13:18-06:00

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

2015-11-17T00:09:43-07:00

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! 🍻😊

Angular Summit 2015

2015-10-01T10:29:31-06:00

I was in Boston this week, speaking and attending the very first Angular Summit. I had the privilege of delivering the opening keynote on Monday. I spoke about the Art of Angular and used a slide deck similar to last time. I did update the presentation to show the astronomical growth of AngularJS in terms of candidate skills (on LinkedIn) and job opportunities (on Dice.com)¹.

I mentioned the recently announced good news for Angular 2:

We're enabling mixing of Angular 1 and Angular 2 in the same application.
You can mix Angular 1 and Angular 2 components in the same view.
Angular 1 and Angular 2 can inject services across frameworks.
Data binding works across frameworks.

In related news, Craig Doremus recently posted a state-geo-angular project that shows how you can develop an Angular 1.x application that will be easy to upgrade to Angular 2.x. Thanks Craig!

Download | SlideShare

After my keynote, I attended Pratik Patel's session on High Performance JavaScript Web Apps. Pratik pointed out mobitest.akamai.com for testing an app's performance and seeing its blocking resources. He also mentioned speedgun.io (currently unavailable) for capturing performance numbers as part of a continuous integration process. Finally, he recommended Addy Somani's JavaScript Memory Management Masterclass.

My second presentation was about JHipster. Near the end of the presentation, I mentioned that I hope to finish the JHipster Book this month. Writing presentations for SpringOne 2GX and the Angular Summit occupied a lot of my free time in September. Now that it's October, I'll be dedicating my free time to finishing the book. In fact, I think I can finish the rough draft this week!

Download | SlideShare

For the last session of the day, I attended John Lindquist's session on Angular 2 Components. John showed us how everything is a component in Angular 2. He also said "now is the time to learn ES6" and built an Angular 2 ToDo App using ES6 and a bit of TypeScript. You might recognize John's name; he's the founder of egghead.io, an excellent site for learning Angular with bite-sized videos.

Tuesday morning started with a Angular 2.0 keynote from Peter Pavlovich. I really enjoyed this session and received lots of good tips about getting ready for Angular 2. The tweet below from Ksenia Dmitrieva shows his advice.

Best Practices for #angularjs 1.X if you plan to switch to 2.0 by @ppavlovich #AngularSummit pic.twitter.com/9nobqDc9G9
— Ksenia Dmitrieva (@KseniaDmitrieva) September 29, 2015

My biggest takeaway was to start following John Papa's Angular Style Guide ASAP.

The first session I attended on Tuesday was Judd Flamm's Google Material Design & Angular. I'm using Material Design for Bootstrap on a side project, so I was interested in learning more about its inspiration. We learned that Google Design has everything you need to know about why Material Design exists. We also learned about Angular Material and spent most of the session looking at its components. Judd recommended Angular Material-Start for those looking to get started quickly with both frameworks. Judd was a very entertaining speaker; I highly recommend you attend one of his talks if you get the opportunity.

After being dazzled by Peter's knowledge of Angular 2 in Tuesday's keynote, I attended two more of his talks: one on Meteor and another on Aurelia. I've known about Meteor for a while, but have become more intrigued by it lately with its 1.2 release and Angular support. Meteor's command line tools that auto-inject CSS and JS demoed very well, as did it's installable features like a LESS support and Facebook authentication.

After hearing all the good things about Angular 2 from Peter, it was interesting to hear him downplay it in his Aurelia talk later that day. When he started showing code, it was pretty obvious that Aurelia is doing a great job of simplifying JavaScript MVC syntax for developers. You can develop components with almost half the code that Angular 2 requires, and it uses ES6, jspm and SystemJS. If you're developing JavaScript, learning these tools will help prepare you for the future. It's cool that Aurelia encourages learning things you should learn anyway.

Aurelia and Angular 2 are both still in Alpha, so I'm not sure it makes sense to use them on a project this year. However, I do think it's important to track them both. I especially think it's interesting that the founder of Aurelia, Rob Eisenberg, left the Angular Team in November 2014 and announced Aurelia in January 2015 (Hacker News thread). Peter mentioned several times that Aurelia wants to help developers write apps, while AngularJS is more tied to helping Google write apps.

There were around 400 people at Angular Summit, which I think is pretty good for a first-run conference. As with most No Fluff Just Stuff shows, it ran smoothly, had plenty of time between sessions and was filled with knowledgeable, entertaining speakers. It was fun doing my first keynote and I look forward to speaking again in November (at Devoxx) and December (at The Rich Web Experience).

1. I know Dice.com is probably not a great site, but it makes sense to use it since I've been tracking JavaScript MVC framework job stats on it since February 2014.

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

2015-07-27T08:08:48-06:00

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.

Getting Hip with JHipster at Denver's Java User Group

2015-04-09T08:31:54-06:00

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.

AppFuse 3.5 Released!

2015-02-20T09:08:53-07:00

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

2015-02-12T09:28:59-07:00

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?

AppFuse, Reduced

2014-12-16T06:03:31-07:00

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.

Developing Services with Apache Camel - Part III: Integrating Spring 4 and Spring Boot

2014-10-08T07:13:18-06:00

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

2014-09-30T10:05:38-06:00

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

2014-09-23T10:58:25-06:00

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.

Why I prefer IntelliJ IDEA over Eclipse

2014-07-21T13:33:55-06:00

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?

Documenting your Spring API with Swagger

2014-03-25T13:07:18-06:00

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.

Comparing JVM Web Frameworks at vJUG

2014-02-06T10:54:17-07:00

A couple months ago, I was invited to speak at Virtual JUG - an online-only Java User Group organized by the ZeroTurnaround folks. They chose my Comparing JVM Web Frameworks presentation and we agreed I'd speak yesterday morning. They used a combination of Google Hangouts, live streaming on YouTube and IRC to facilitate the meeting. It all went pretty smoothly and produced a comfortable speaking environment. To practice for vJUG, I delivered the same talk on Tuesday night at the Denver Open Source Users Group.

The last time I delivered this talk was at Devoxx France in March 2013. I didn't change any of the format this time, keeping with referencing the Paradox of Choice and encouraging people to define constraints to help them make their decision. I did add a few new slides regarding RebelLabs' Curious Coder’s Java Web Frameworks Comparison: Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF and The 2014 Decision Maker’s Guide to Java Web Frameworks.

I also updated all the pretty graphs (which may or may not have any significance) with the latest stats from Dice.com, LinkedIn, StackOverflow and respective mailing lists. Significant changes I found compared to one year ago:

Job Listings on Dice.com
- Play Framework job listings increased almost 4x
- Tapestry jobs are 1/3 of what they were a year ago
- Wicket jobs are 1/2 of what they were a year ago
- JavaScript framework jobs are up quite a bit: Ember.js up ~300%, AngularJS up 900%, Backbone up 160%
LinkedIn Skills
- Rails down ~30%
- Grails up 25%
- Play Framework up 200%
- Spring Roo up 40%
- Ember.js up 300%
- AngularJS up 840%
- Backbone up 200%

As you can tell from these findings, AngularJS has gained quite a bit of mindshare in the last year. There's a lot of companies looking for JavaScript skills and quite a few folks have added JavaScript frameworks to their LinkedIn profiles.

You can watch the recording on YouTube or click play in the embedded video below.

You can also quickly browse the slide deck below, download the PDF or view it on SlideShare.

Thanks to all the folks who attended these talks. And thanks to @dosug and @virtualjug for giving me the opportunity to speak.

AppFuse 3.0 Released!

2013-12-23T14:31:15-07:00

The AppFuse Team is pleased to announce the release of AppFuse 3.0. This release is AppFuse's first release as a 10-year old and includes a whole slew of improvements.

Java 7 and Maven 3 are now minimal requirements
Replaced MyFaces and Tomahawk with PrimeFaces for JSF
- Removed SiteMesh in favor of JSF's built-in layout support
Added Wicket support
Migrated from jMock to Mockito for tests
Integrated wro4j and WebJars
Migrated to Bootstrap 3 and defaulted to Bootswatch's Spacelab theme

In addition, this release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are Spring 4, Spring Security 3.2 and Bootstrap 3. For more details on specific changes see the release notes.

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

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

JavaOne 2013: Videos of Presentations on Parleys

2013-12-13T09:40:42-07:00

This year marked my first time speaking at JavaOne. It seems to have gone well, especially since audience feedback resulted in a JavaOne Rock Star Award. I'm very humbled to be listed with some really great speakers. Congratulations to all the other Rock Stars - as well as everyone that had the courage to submit and present a talk this year!

For the top sessions at JavaOne 2013, Oracle worked with Parleys to capture the audio and synch it with the presentations. They published them in a JavaOne 2013 Channel and my presentations were included. Without further ado, here they are for your viewing pleasure.

If you happen to watch these and have any feedback, please leave a comment or send a tweet to @mraible.

Devoxx 2013 + a Nordic Countries Speaking Tour

2013-11-28T12:07:26-07:00

Two weeks ago, Trish and I boarded a flight for one of our favorite conferences: Devoxx. After a brief layover in Frankfurt, we arrived in Amsterdam and took a train to Antwerp. Within hours, we'd settled into our hotel near the center of Antwerp and strolled over to the dungeonous, yet cozy, Pelgrom restaurant. We were hoping for a delicious dinner, but found much more. We ran into James Ward, Dick Wall and a number of other enthusiastic speakers from the conference. Since I had to speak the next day, we didn't stay long, but we did share a number of laughs with some great people.

Tuesday (November 12), was a University Day at Devoxx, and I had my talk that afternoon. I spent a couple hours finishing up my talk that morning, then grabbed a taxi to head to the conference. I was honored with the opportunity to speak in Room 8, which is a huge theater that holds several hundred people.

I presented a lengthened version of The Modern Java Web Developer presentation I did early this year (at Denver's JUG and JavaOne). Based on your feedback, I chose to do deep dives on AngularJS, Bootstrap and Page Speed. I've always enjoyed speaking at Devoxx because attendees are so enthusiastic and passionate about the conference. I received an immense amount of feedback, both in praises and criticisms. The critics indicated there were too many buzzwords and not enough substance. Others complained that the AngularJS Lipsync that I did was too deep.

I made sure to review and process everyone's comments, and then used them to improve the presentation throughout the following week. I learned to elaborate on the fact that many of the technologies were important to know about, but not important to know through-and-through. I made sure to mention that the use of CoffeeScript and LESS is often limited (or embraced) by team members and their willingness to try new things. If you're not writing thousands of lines of JavaScript or CSS, it probably doesn't make sense to use these languages. Furthermore, if your team members are struggling to write JavaScript or CSS, introducing a new language is probably not the best thing. I also reminded people to be skeptical of new technology, but also to be open-minded and give everything a chance. The 10-minute, download-and-try test, is a great way to do that.

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

Within this presentation, there are links to each of the deep dives. The last two are screencasts that I added audio to a few days ago.

Bootstrap 3 | AngularJS Deep Dive | Page Speed Demo

We stayed in Antwerp until Friday, attending the conference, taking pictures, networking over beers and having a fabulous time with everyone attending Devoxx.

Thursday night, we dined at Matty, one of the best restaurants in Antwerp. The food was excellent and provided a nice start for a night that included the Devoxx Party at Noxx and a journey to Bier Central.

On Friday, we traveled to Brussels for a weekend in one of the best beer cities in the world. Trish booked us a room at the Hotel Saint Michel, which was right on the most beautiful square in Europe. Their pre-Christmas light show was spectacular. The beer was delicious, the location was magnificent and we thoroughly enjoyed ourselves, especially the mussels in Brussels. Thanks in particular to Stéphane and Philip for your recommendations.

Nordic Countries Speaking Tour
On Sunday (November 17), we flew to Stockholm to being the second half our trip. Nordea hired me to deliver my Devoxx presentation as part their Java Competence Network. Nordea's Jonny Berggren first contacted me in March 2010 about this opportunity, so it was fun to see it finally happen. We agreed that I'd speak at their four main locations: Stockholm, Helsinki, Oslo and Copenhagen.

Mattias Karlsson (of Jfokus fame) also presented me with an opportunity to speak at his company while I was in Sweden.

I started the week delivering my talk on Monday afternoon at Nordea. Then we met up with Mattias, walked to his company and I delivered it again 45 minutes later. It was exhausting to talk for six hours in one day, but it all seemed to go well. I especially enjoyed the enthusiasm of Mattias's Avega Group.

That evening, we took the train to the airport, boarded a flight to Helsinki and arrived just after midnight. While on the train, we sat next to a Finlander, Karol, that gave us all kinds of great advice on what to do. Tuesday in Helsinki was cold and dreary; perfect sauna weather. We walked around a bit in the rain that morning and visited Senate Square on Karol's recommendation. I mentioned to the developers there that my Mom's grandparents were from Finland (Oulu and Hamina), and that I'd grown up in a rustic cabin built by my Finish grandfather, Matti Hill.

We flew to Oslo Tuesday evening, rode the super-fast train from the airport and got to bed just before midnight. Wednesday morning, we walked around the Vigelandsparken Sculpture Park, and then I headed to the Nordea office while Trish did a walkabout and rode a Viking ship around the bay. We met up afterwards at the wonderful Beer Palace for some pizza and delicious German/Belgian beer.

Copenhagen was our last stop, a city which neither of us have ever traveled to. After arriving, we quickly got a hint that Copenhagen was a special place. We did a bit of research on Wikipedia and learned it was The City of Bikes and their craft brewing industry has blossomed in the last decade, now sporting over 100 microbreweries. My last talk on Thursday morning went very well, especially since my presentation and advice was well polished by that point.

That afternoon, we rented bikes from our hotel, slowly ate sushi on the top of the Tivoli Hotel, and then rode to Tivoli Gardens. Tivoli Gardens was decorated as a Christmas wonderland and their amusement park made us smile and giggle with glee. We stayed there for hours before riding home. Biking around town with hundreds of other cyclists was really cool and fun. I hope Denver gets Copenhagenized someday, the abundance of bike-only roads is simply awesome.

Our Nordic countries tour was especially pleasant because Christmas decorations were everywhere. In the US, many folks look down upon Christmas decorations before Thanksgiving, but since Europeans don't celebrate Thanksgiving - there's no reason not to ease into the Christmas spirit. We figured Abbie and Jack would have a blast at Tivoli in a future November or December. Yes, it was a bit chilly (20-30°F) in most of the countries, but we were well dressed for it. Unfortunately, we didn't get to see any snow.

Many thanks to Devoxx, Nordea, Mattias's Avega Group and the hundreds of developers who listened to me talk about being a modern web developer. We had a wonderful time speaking, laughing, photographing, drinking your delicious beer and seeing all your smiling faces.

For more photos of this whirlwind trip, see Trish's EU and Scandanavian Speaking Tour 2013, while mine are in Devoxx 2013 and Nordic Speaking Tour.

The Modern Java Web Developer Bootcamp at Devoxx

2013-10-29T10:21:49-06:00

At this year's Devoxx, I'll be delivering my first University session. University talks are in depth presentations of 3 hours (= 75m + 30m break + 75m). I'm calling it The Modern Java Web Developer Bootcamp and my goal is to teach people some new concepts and techniques that'll make them more valuable developers. My session's hashtag is #dv13-javaweb$ to exemplify the important takeaways: Java is back, web development is fun and you can make more money.

Three hours is quite a bit longer than I'm used to, but I'm confident I can fill the time with lots of knowledge. My plan is to enhance my presentation from JavaOne and add a few demos. Currently, I'm thinking of developing the following additional content:

HTTP Overview (with SPDY)
Polymer and Web Components
Bootstrap 3 Overview
HTML5 Storage
API Framework Comparison (Play, Grails, Dropwizard)
Load Testing
Performance Monitoring (including RUM)
Internal Cloud Options

For demos, I'd like to show a few that provide real value to attendees and teach them how to do something they haven't done before. The ones below are candidates I'm thinking of, and I'd like to pick three for the final presentation.

Browser Tools Demo
Developing with Bootstrap Demo
AngularJS Demo
Refactor an app from Spring to Java EE, no XML, all Java 8
Page Speed Improvement Demo
Security Demo (add LDAP to Angular app + OWASP ZAP)

If you could pick three real-time tutorials from the choices above, which ones would you choose?

I'm also thinking of adding some stories about impressive loads served with very little hardware and real-time dashboard development. If you have a story about either of these, please let me know. I'd be happy to credit you (or your company) and talk about any technical implementation details you're willing to provide.

Writing for InfoQ

2013-10-20T09:20:08-06:00

A little over six months ago, I received an email from Charles Humble, the lead Java editor at InfoQ.com. He asked me to comment on his Struts 1 Reaches End Of Life. I happily obliged, and my thoughts were published as part of the article.

After that brief interaction, Charles and I started talking about the possibility of writing for InfoQ. I said I'd be interested and things have been progressing steadily from there. Today, I'm proud to announce that my first InfoQ article has been published. If you missed JavaOne, or attended but didn't see the keynotes, you might enjoy reading JavaOne 2013 Roundup: Java 8 is Revolutionary, Java is back.

If you did attend JavaOne, or simply watched the JavaOne Keynotes and found something particularly intriguing, I'd love to hear about it.

JavaOne 2013: My Presentations

2013-09-27T13:35:01-06:00

I flew into San Francisco this past Monday to speak at JavaOne 2013, and to meet with my new client. I made sure to wear a Broncos shirt since I was riding the train through Oakland and had some co-workers that were Raiders fans. My trip started off nicely as the Broncos dismantled the Raiders on Monday Night Football. My new team and I watched it during a team dinner at Havana in Walnut Creek. Historically, the Broncos and Raiders have had a heated rivalry historically, so the win was the perfect start to the week.

On Tuesday, I worked from my hotel in the morning, then met James Ward to do some last minute prep for our smackdown. The prior week, we both upgraded our respective apps to use the latest versions of Grails and Play Framework. I ran into a few issues when upgrading, while Play required some API changes.

We both added Memcachier to our apps (to share caching between dynos) and ran some Apache Bench tests. The results showed quite a bit of slowdown compared to last time, which we attributed to caching needing to make network hops. Other than that, we both had to make changes to our framework's buildpacks to get the latest versions running on Heroku, and when we headed for our talk, my instance of Grails wasn't running (60 second boot timeout on startup). The good news is it somehow solved its issues during our talk and was up and running when I checked it after, as it is now. Below is an embedded version of the presentation we delivered. You can also click here to see it in a new window, or view it on SlideShare.

On Wednesday morning, I tried to attend Venkat's Programming with Lambda Expressions in Java, but quickly discovered it was sold out. My talk on The Modern Java Web Developer started shortly after and I had a fantastic time talking to a packed room and preaching the virtues of learning and staying up-to-date with web technologies. I made sure to include a slide on Avatar, an Oracle-sponsored JavaScript-based framework that requires "very minor JavaScript knowledge". You can view my presentation below or on SlideShare.

According to @JavaOneConf, all JavaOne 2013 presentations will be published on Parleys.com.

After completing my talks, I journeyed to my client and practiced what I preached, successfully finishing a spike that reduced page load time from 8 seconds to 2 seconds. That evening, I attended the Oracle Appreciation Event at Treasure Island, had some cold beer and listened to some loud music.

I had a great time speaking at JavaOne this year, and look forward to my next speaking engagement. In November, I'll be traveling to Devoxx where I'll be giving a 3-hour University session on The Modern Java Web Developer. Hope to see you there!

The Modern Java Web Developer and Java Web Security at Denver JUG

2013-02-14T10:23:18-07:00

Last night, I had the pleasure of delivering two talks at the Denver Java User Group. The first talk, The Modern Java Web Developer, was inspired by the book titled The Well-Grounded Java Developer. Ben Evans and Martijn Verburg mention in the beginning of the book that they wrote it as a training guide to get new Java developers up to speed. For my talk, I wanted to do something similar, but for Java Web Developers.

I mentioned that the first thing you have to do to become modern is to change your title from a Java Web Developer to a JVM Web Developer. After doing that, you have a whole slew of new and wonderful technologies at your disposal. From there, I believe the Modern JVM Web Developer:

Starts with Fast Hardware
Uses IntelliJ IDEA
Leverages jQuery, HTML5, and CSS3
Creates High Performance Web Sites
For Mobile Devices
In the Cloud
And cares about Security

You can also view this presentation on Slideshare or download it from my presentations page.

The second talk was on Java Web Application Security and was largely an updated version of the talk I gave a couple years ago, starting with an appearance at the Utah JUG. It was mostly a live demo session using my Ajax Login application. To prepare the project for this talk, I created branches for each step. This means you can checkout the "baseline" branch and use Git to compare it with the "javaee" branch. You can also compare the "spring-security" branch vs. the "apache-shiro" branch. Finally, you could see what I needed to do to fix many of the vulnerabilities found by Zed Attack Proxy.

You can also view this presentation on Slideshare or download it from my presentations page.

Thanks to the DJUG and Thrive folks for providing good beer (especially the Guinness!) and FullContact for hosting. Also, I'd like to thank Manning for the copies of The Well-Grounded Java Developer they sent and No Starch Press for copies of Michal Zalewsky's The Tangled Web: A Guide to Securing Modern Web Applications. Last, but certainly not least, thanks to all the good people who attended and listened to me ramble on about all this cool technology.

Future speaking engagements include Devoxx France in March and Denver's HTML5 User Group in April.

AppFuse Light 2.2.1 Released!

2013-01-24T19:43:20-07:00

In December, the AppFuse Team released 2.2.1. Right before that release, I decided to wait on enhancing its "light" modules, a.k.a. AppFuse Light. I'm glad I did, because it took some effort to get jQuery and Bootstrap integrated, as well as to make it more secure.

The good news is AppFuse Light 2.2.1 is released and it's sitting out on the Central Repository. This release is a refactoring of all archetypes to be up-to-date with the AppFuse 2.2.1 release. This means Java 7 compatibility, Servlet 3, Bootstrap/jQuery integration, Tapestry 5.3.6 upgrade and security improvements. I integrated Bootstrap and jQuery using WebJars Servlet 3 support since it was simple and straightforward.

You can create projects using AppFuse's light archetypes using a command such as the following:

mvn archetype:generate -B -DarchetypeGroupId=org.appfuse.archetypes 
  -DarchetypeArtifactId=appfuse-light-spring-freemarker-archetype -DarchetypeVersion=2.2.1 
  -DgroupId=com.mycompany -DartifactId=myproject

The list of archetypes is as follows:

appfuse-light-jsf-archetype
appfuse-light-spring-archetype
appfuse-light-spring-freemarker-archetype
appfuse-light-spring-security-archetype
appfuse-light-stripes-archetype
appfuse-light-struts-archetype
appfuse-light-tapestry-archetype
appfuse-light-wicket-archetype

The QuickStart Guide will help you get setup and demos are available at the following links:

If you have questions about AppFuse, we invite you to ask them on the users mailing list or tweet using #appfuse.

For those enjoying Bootstrap in your apps, I encourage you to check out {wrap}bootstrap and Bootswatch.

AppFuse 2.2.1 Released!

2012-12-11T15:21:44-07:00

The AppFuse Team is pleased to announce the release of AppFuse 2.2.1. This release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are Hibernate 4, Struts 2.3.7, Apache CXF 2.7.0 and Spring Security 3.1.3. In addition, we've integrated HTML5, Twitter Bootstrap, jQuery and replaced Compass with Hibernate Search. Last but not least, we've added full support for Java 7 and integrated many security improvements. For more details on specific changes see the release notes.

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

A number of blog posts were written about features that went into this release while it was being developed:

If you have questions about AppFuse, please read the FAQ or join the mailing list. If you find any issues, please report them on the users mailing list.

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. We highly recommend using the new IntelliJ IDEA 12 for developing web applications.

The Well-Grounded Java Developer Book Review

2012-11-21T09:54:25-07:00

After finishing Core HTML5 Canvas, I dived into the next book on my list: The Well-Grounded Java Developer by Ben Evans and Martijn Verburg. I've known about this book since April of last year when I received an email from Martijn. He wanted to use some of my graphs and research on JVM Web Frameworks as evidence that many frameworks aren't meeting developer's needs and to support their coverage of Grails in the book.

I agreed and also did a quick review on Chapter 13, Rapid Web Development. In June of this year, I received another email saying the book was done and they'd send me a free copy. I received the book in early August, but didn't start reading it until mid September.

The book is broken up into 4 separate parts:

Developing with Java 7
Vital techniques
Polyglot programming on the JVM
Crafting the polyglot project

Developing with Java 7
The first two chapters on Java 7 and NIO.2 (aka JSR-203) were great in that I started learning new things immediately. While I knew about most of the changes (strings in switch statements, improved exception handling, try-with-resources, diamond syntax, etc.), it was a nice refresher and motivated me to install Java 7 and start using it on a daily basis. The NIO.2 chapter covers the new filesystem support with Path, the Files helper class and Asynchronous I/O.

It was around this same time that I started on Coursera's Functional Programming Principles in Scala. I quickly realized the course was going to take quite a bit of my free time (5-7 hours per week). It was a good challenge to try and read for 30 minutes a day as well as stay on top of my Scala homework. However, it was also highly rewarding in all the knowledge I received in the last two months.

Vital techniques
This section covers Dependency Injection, Concurrency, Class files, and Bytecode and Performance Tuning. I skimmed through the DI chapter but slowed down to try and get my head around concurrency. Then I thanked my lucky stars I haven't had to deal with it much. I found the class files and bytecode chapter mildly interesting but perked up again to learn more about how to do performance tuning, VisualVM, and the new G1 garbage collector.

Polyglot programming on the JVM
The polyglot programming section was largely a reinforcement of my existing knowledge since I've used Groovy and Scala quite a bit. The chapter on Clojure was an eye-opener since I hadn't used Clojure before. I wasn't quite convinced of its merits, but I did learn enough to read and understand its syntax. Reading the Scala chapter while doing the Coursera course made me realize that Ben and Martijn really packed a lot into each language's chapter. This section is really a great intro to all these languages, especially if you've never worked with them before.

Crafting the polyglot project
While the final section was good, I learned the least in this section. While the concepts discussed in this section are important, they're also things I've been using for years: TDD, CI, and Rapid Web Development (with Grails). This section touched on Hibernate when discussing TDD and I thought to myself - it's strange they don't have cover Hibernate (or JPA) as part of being a well-grounded Java developer. My guess is the authors assumed most Java devs already know it.

The final chapter had a lot of tips on staying well-grounded (what's coming in Java 8, how the JVM is supporting polyglot programming, future concurrency trends, and new directions in the JVM).

I really enjoyed this book and feel I became a more knowledgeable Java developer by reading it. It contained a lot of high-level concepts as well as nitty-gritty details. In my opinion, the sign of a great book is one that you feel you'll refer back to as a reference guide. The first half of this book definitely feels like something I'll refer back to. The second half I'll recommend to Java developers wanted to get caught up with the latest trends.

Nice work Ben and Martijn!

Why the bias against JSF?

2012-11-08T09:24:27-07:00

In my last post about InfoQ's Top 20 Web Frameworks for the JVM, I received a thought-provoking comment from henk53:

There is one little thing that does bother me in those presentations, and that's your fairly obvious bias against JSF.
...
If you are presenting yourself as, more or less, an authority on comparing web frameworks, then having a fairly obvious biased against one of them is just peculiar. I, all of my team, and various clients distrust your ranking of JSF. We do look at your data if the choice is between other frameworks, but as soon as JSF comes into the picture we just look elsewhere.

I'm not really sure where this bias comes from. Yes, JSF 1.0 sucked and 1.2 was only marginally better, but 2.0 is really cool and productive and there are SUPERB component and utility libraries now like PrimeFaces and OmniFaces. As a researcher of this topic I think you should keep up the date and not stick to some old grudge.

This is true, I am biased against JSF. It all started with my first JSF experience back in August 2004. If you remember correctly, 2004 was a big year: JSF 1.0, Spring 1.0 and Flex 1.0 were all released. The "AJAX" term was coined in early 2005.

By 2007 and 2008, JSF still hadn't gotten any better. In late 2009, JSF 2.0 was released and I upgraded in March 2011. As you can see from the aforementioned post, I ran into quite a few issues upgrading. JSF was also the hardest one to get working with extension-less URLs.

Most of my issues with JSF come from having maintained an application built with it since 2004. If I were to start a new application without any legacy migration issues, I imagine it wouldn't be as difficult. However, if you compare it to Struts 2 and Spring MVC, I've had little-to-no issues upgrading those applications over the years.

Also, I'm not just biased against JSF, but most component-based web frameworks. Just ask the Tapestry and Wicket folks. They've felt my criticisms over the years. My reason for preferring request-based frameworks like Struts 2/Spring MVC and Grails/Play has been because I've never seen the appeal in component-based frameworks. Often I've found that their components are just widgets that you can get from any decent JavaScript framework. And chances are that JavaScript framework can work with any web framework. Also, I've worked on a lot of high-traffic web applications that require statelessness for scalability.

I see the value in component-based frameworks, I just don't think components should be authored on the server-side. Most of the Java-based component frameworks require 2+ files for components (one for the component, one for the view, possibly one for the config). I love GWT's component concept in that you can just extract a class and re-use it. With JS frameworks, you can often just include a script. These days, when I think of good component-based frameworks, I think of jQuery UI and Twitter Bootstrap.

All that being said, there's a lot of folks praising JSF 2 (and PrimeFaces moreso). That's why I'll be integrating it (or merging your pull request) into the 2.3 release of AppFuse. Since PrimeFaces contains a Bootstrap theme, I hope this is a pleasant experience and my overall opinion of JSF improves.

In other component-based frameworks in AppFuse news, Tapestry 5 has gotten really fast in the last year. I imagine this is because we have a Tapestry expert, Serge Eby, working on it. And we're planning on adding Wicket in the 2.3 release.

So even though I prefer request-based frameworks with REST support and Bootstrap, that doesn't mean everyone does. I'll do my best to be less-biased in the future. However, please remember that my view on web frameworks is as a developer, not an analyst. And aren't developers supposed to be opinionated?

Deploying Java and Play Framework Apps to the Cloud with James Ward

2011-11-18T08:14:45-07:00

Yesterday, I attended James Ward's presentation on Deploying Java & Play Framework Apps to the Cloud at Devoxx. I arrived a bit late, but still managed to get there in time to see a lot of demos and learn more about Heroku. Below are my notes from James's talk.

When I arrived, James was doing a demo using Spring Roo. He was using Roo's Petclinic sample app and showed us how you could use Git to create a local repository of the new project and install Heroku's command line tool. From there, he ran the following command to create a new application on Heroku.

heroku create -s cedar

The Cedar Stack is what supports Java, Scala and Play Framework. It's the 3rd generation stack for Heroku. The command above created two endpoints, one for HTTP and one for Git. It picks from a list of randomly generated names, which all seem to have some humor in them. James ended up with "electric-sword-8877" for this demo.

From there, he ran git push heroku master to deploy the project to Heroku. Unfortunately, this resulted in a login error and there was an akward moment where we all thought the Demo Gods were angry. However, James was able to resolve this by using Heroku's sharing feature with the following command.

heroku sharing:add jw@heroku.com

For Java projects, Heroku looks for a pom.xml file in the root directory and runs a Maven build on project. All the dependencies get downloaded on the cloud rather than put them into a WAR and requiring you to upload a large WAR file. You don't have to upload your source code to Heroku; James did it for the sake of the demo because it was faster.

After the build finishes, it creates a slug file. This file contains everything Heroku needs to run your application.

Next, James showed a demo of the running application and added a new Pet through its UI. Then he scaled it to two servers using the following command:

heroku scale web=2

He proved this was working by running heroku ps, which showed there were two running processes. He showed the app again, but noted that the record he added was missing. This is because when it started up a new dyno, Hibernate created the schema again and deleted all records. To fix, James changed Hibernate to only update the schema instead of create a new one. If you're a Hibernate user, you know this is as simple as changing:

hibernate.hbm2ddl.auto=create

to:

hibernate.hbm2ddl.auto=update

After committing this change, James redeployed using Git.

git push heroku master

The slug file got built again and Heroku deployed the new slug onto both dynos, automatically load balancing the app across two servers. James then ran heroku logs to see the logs of his dynos and prove that a request to his app's HTTP endpoint made requests to both dynos. The logging is powered by Logplex and you can read about how it works in the article Heroku Gets Sweet Logging.

James mentioned that Roo has a Heroku plugin, but after watching his talk and searching a bit on the internet, it seems it's just the jetty-runner setup as described in Getting Started with Spring MVC Hibernate on Heroku/Cedar.

What about autoscaling? There are some 3rd party tools that do this. Heroku's Management infrastructure has APIs that these tools talk too. Heroku hasn't built autoscaling into the platform because they don't know where the bottlenecks are in your application.

Heroku = Polyglot + PaaS + Cloud Components. It supports Ruby, node.js, Java, Clojure, Play and Scala and they're working on native Grails and Gradle support. There's currently 534,374 apps running on Heroku.

Heroku is a cloud application platform and there's 5 different components.

Instant deployment
HTTP Routing / Load Balancing
Elastic Polyglot Runtime
Management & Logging
Component as a Service Ecosystem

For instant deployment, it's a pretty simple process:

You add files to a git repo
You provision the app on Heroku (heroku create)
You upload the files to Heroku (git push heroku master)
Heroku runs the build and assembles a "slug" file
Heroku starts a "dyno"
Heroku copies the "slug" to the "dyno"
Heroku starts the web application

Most apps will contain a Procfile that contains information about how to run the web process. For Spring Roo, it has:

web: java $JAVA_OPTS -jar target/dependency/jetty-runner.jar --port $PORT target/*.war

So how does Heroku decide what application server to use? It doesn't, you do. You need to get your application server into the slug file. The easiest way to do this is to specify your application server as a dependency in your pom.xml. In the Roo example, James uses the maven-dependency-plugin to get the jetty-runner dependency and copy it to the target directory. On Heroku, you bring your application server with you.

Heroku gives you 750 free dyno hours per app, per month. For developers, it's very easy to get started and use. Once you extend past one dyno, it's $.05 per dyno hour, which works out to around $30/month. It's only when you want to scale beyond one dyno where you get charged by Heroku, no matter how much data you transfer. Scalatest is running on Heroku. It has one dyno and is doing fine with that. Bill Venners doesn't have to pay anything for it.

java.herokuapp.com is a site James created that allows you to clone example apps and get started quickly with Heroku's Cedar Stack.

For HTTP Routing, Heroku uses an Erlang-based routing system to route all the HTTP requests across your dynos. Heroku doesn't support sticky sessions. Distributed session management does not work well, because it does not scale well. Heroku recommends you use a stateless web architecture or move your state into something like memcached. Jetty has (in the latest version) the ability to automatically serialize your session into a Mongo system. This works fine on Heroku. The problem with this is if you have 2 dynos running, each request can hit a different dyno and get different session state. Hence the recommendation for an external storage mechanism that can synchronize between dynos.

You can also run non-web applications on Heroku. You can have one web process, but as many non-web processes as you want.

Heroku has native support for the Play framework. To detect Play applications, it look for a conf/application.conf file. You don't need to have a Procfile in your root directory because Heroku knows how to start a Play application.

At this point, James created a new Play application, created a new Heroku app (he got "young-night-7104" this time) and pushed it to Heroku. He created a simple model object, a controller to allow adding new data and then wrote some jQuery to show new records via Ajax and JSON. He also showed how to configure the application to talk to Heroku's PostgreSQL database using the DATABASE_URL environment variable. He explained how you can use the heroku config command to see your environment variables.

The reason they use environment variables is so Heroku can update DATABASE_URL (and other variables) without having to call up all their customers and have them change them in their source code.

Play on Heroku supports Scala if you create your app with Scala. Play 2.0 uses Scala, Akka and SBT. Heroku added support for SBT a couple month ago, so everything will work just fine.

Heroku also supports Scala, detecting it by looking for the build.sbt file in the root directory. Heroku supports SBT 0.11.0 and it builds the 'stage' task. It currently does not support Lift because Lift uses an older version of SBT and because it's a very stateful framework that would require sticky sessions. Use Play, BlueEyes or Scalatra if you want Scala on Heroku.

Heroku has addons for adding functionality to your application, including Custom DNS, HTTPS, Amazon RDS, NoSQL and many more. They're also working on making their add-on and management APIs available via Java, so you'll (hopefully) be able to use them from your IDE in the future.

From there, James showed us how Heroku keeps slug files around so you can do rollbacks with heroku rollback. He also showed how you can use:

heroku run "your bash command"

to run any Bash command on the cloud.

Summary
I attended James's talk because he's a good friend, but also because I've been using Heroku to host my latest adventures with Play, Scala, CoffeeScript and Jade. I'm glad I attended because I learned some good tips and tricks and more about how Heroku works.

Heroku seems like a great development tool to me. In my experience, it's been really nice to have instant deployments using Git. In fact, I've created a 'push' alias so I can push to my project's repo and heroku at the same time.

alias push='git push origin master && git push heroku master'

I'd like to see more organizations embrace something like Heroku for developers. It'd be great if everyone had their own sandbox that business owners and product managers could see. I can't help but think this would be awesome for demos, prototyping, etc.

There were some other talks I wanted to attend at the same time, particularly Martin Odersky's What's in store for Scala? and WWW: World Wide Wait? A Performance Comparison of Java Web Frameworks. The WWW talk has posted their presentation but I'm sure it'd be more fun to watch.

It's pretty awesome that all the talks from Devoxx 2011 will be up on Parleys.com soon.

Update: James has posted his slides from this talk.

How do you get started in programming?

2011-07-28T11:12:09-06:00

I recently received the email below from someone asking how he might get started in programming. I think this is a popular topic, especially given the current economic situation in the US (unemployment is high, but not in the tech industry). For that reason, I figured I'd post my response here and allow others to chime in with their advice.

I read about you on LinkedIn, forgive my intrusion. Since you seem like an expert in the field of designing websites I wanted to know your thoughts on switching into this field late in life. I am 41 and looking to make the move from an unrelated field (finance) to programming. So far I have learned HTML, CSS and some Javascript. I have taken classes on C and Java. I have made some basic Android phone apps.

What languages do you think I should focus on? What is the fastest way to get up to speed to make a career of it? Classes? Take a entry level job? Study on my own?

Thanks for any insights….

My reply:

It's interesting that you're switching from finance to programming. I did the same thing early on in my career, but I was fortunate enough to do it in college (I have degrees in Russian, International Business and Finance) and therefore able to audit some CS classes before I graduated.

I think the most valuable skills these days are front-end skills (HTML, CSS and JavaScript). If you can combine those skills with the ability to design websites, you'll go along way. I've taken a different approach where I have excellent front-end skills, but also know a lot about the backend.

While it helps to have a Java background these days, the real sweat spot is the JVM and the containers that run on it like Tomcat and Jetty. A lot of Java developers are learning Groovy and Scala, but unfortunately a lot of their documentation/books are targeted towards Java developers.

The fastest way to get up-to-speed on it is to start your own project (if you can't get a company to hire you to do it). I'd suggest creating a webapp that solves a problem that you have, makes your life easier, etc. If you open source it and build a community around it, that's just as good as working for a company as far as experience goes. Combine this with studying on your own and you can likely come up to speed very quickly.

As a programmer, what advice do you have for someone looking to switch careers, or get into our industry fresh out of college?

Installing OpenJDK 7 on OS X

2011-07-12T14:11:44-06:00

Last week, I scanned an article and saw there was a Java 7 Webinar. At first, I thought Java 7 was released, but soon after realized it was a Developer Preview. Unfortunately, the download page doesn't have support for OS X. Since it took me a bit of work to figure out how to install OpenJDK 7 on OS X (I'm running Snow Leopard 10.6.7), I figured I'd write down how I did it.

I started off by downloading "OpenJDK 1.7 universal (32/64 bits) from Mac OS/X branch" from the openjdk-osx-build project's downloads (direct link). After downloading, I installed the dmg as normal.

Update Jan 27, 2012:
After installing the dmg, add the following to your ~/.profile and you should be good to go. Thanks to Mark Beaty for the tip.

function setjdk() { if [ $# -ne 0 ];then export JAVA_HOME=`/usr/libexec/java_home -v $@`; fi; java -version; }

Continue with the instructions below if you don't like this technique for some reason.

I don't use Java Preferences to set my JDK, instead I use David Blevin's handy setjdk script. To make this script work with JDK 7 on OS X, I had to make one minor change. On line 40, I added "Contents" to the path for JAVA_HOME:

export JAVA_HOME=$vmdir/$ver/Contents/Home

Update Jan 27, 2012: You no longer need to make this change.

From there, I had to setup some symlinks so everything would work as expected:

cd /System/Library/Java/JavaVirtualMachines/
sudo ln -s /Library/Java/JavaVirtualMachines/1.7.0.jdk

Update Jan 27, 2012: The latest version installs at a different location so the symlink command above should be changed to:

sudo ln -s /Library/Java/JavaVirtualMachines/1.7.0u.jdk 1.7.0.jdk

Lastly, I had my JAVA_HOME set to "/System/Library/Frameworks/JavaVM.framework/Home". I like the shorter (and seemingly more common) "/Library/Java/Home", so I set it back to that in my ~/.profile:

export JAVA_HOME=/Library/Java/Home

On my system, /Library/Java/Home had a symlink to /System/Library/Frameworks/JavaVM.framework/Home, so I changed it to the CurrentJDK that Java Preferences and setjdk use.

cd /Library/Java
rm Home
ln -s /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Contents/Home

Then I had to add a symlink for 1.7 in the Versions directory.

cd /System/Library/Frameworks/JavaVM.framework/Versions
sudo ln -s /System/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents 1.7

After making these changes, I was able to switch to JDK 7 easily.

$ setjdk 1.7
Setting this terminal's JDK to 1.7 ... openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

I was also able to switch back to JDK 6.

$ setjdk 1.6
Setting this terminal's JDK to 1.6 ... java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)

Maven Issues
Next, I tried using JDK 7 to build AppFuse. I ran into two issues when I tried to do this. The first was caused by the native2ascii plugin, which has been known to cause issues on non-Mac platforms. Adding the following profile seemed to solve the problem.

<profile>
    <activation>
        <jdk>1.7</jdk>
    </activation>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>native2ascii-maven-plugin</artifactId>
                <dependencies>
                    <dependency>
                      <groupId>com.sun</groupId>
                      <artifactId>tools</artifactId>
                      <version>1.7.0</version>
                      <scope>system</scope>
                      <systemPath>${java.home}/../lib/tools.jar</systemPath>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
</profile>

The next issue was with Enunciate and its maven-enunciate-cxf-plugin.

[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] com/sun/mirror/apt/AnnotationProcessorFactory
com.sun.mirror.apt.AnnotationProcessorFactory
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory

It seemed like adding a profile that included tools.jar would solve this, but it doesn't. When I add the dependency directly to the plugin itself, I get the following error:

warning: The apt tool and its associated API are planned to be
removed in the next major JDK release.  These features have been
superseded by javac and the standardized annotation processing API,
javax.annotation.processing and javax.lang.model.  Users are
recommended to migrate to the annotation processing features of
javac; see the javac man page for more information.
[WARNING] Validation result has errors.
error: [core] java.lang.StackTraceElement: A TypeDefinition must have a public no-arg constructor or be annotated with a factory method.
1 error
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

Hopefully this article helps you get started with Java 7 on OS X. If you have any additional tips, please leave a comment.

My Java Web Application Security Presentation from Jazoon 2011

2011-06-24T06:25:55-06:00

Yesterday I delivered my Java Web Application Security talk at Jazoon. The presentation I gave was similar to the one I delivered at Utah JUG, but contains a few more slides about penetration testing and securing REST APIs. I also opted not to embed the screencasts in the presentation on SlideShare since you can click on the links to view them. Lastly, I included a great quote from Erlend Oftedal, who left a great comment on my last post.

"Security is a quality, and as all other quality, it is important that we build it into our apps while we are developing them, not patching it on afterwards like many people do."

If you'd like to download a PDF of this presentation, you can do it from Slideshare or from my presentations page.

Like most conferences in the last year, I brought the lovely Trish McGinity with me. As of today, it's been one year since I saw her switch from a Martini to a Guinness and thought "I need to talk to that girl!" It's been a heckuva a ride ever since and I'm sure the future will be just as much fun. To celebrate, we're going to explore Rhine Falls and have dinner at Greulich. Happy Anniversary Trish!

Java Web Application Security - Part V: Penetrating with Zed Attack Proxy

2011-06-21T07:45:41-06:00

Web Application Security is an important part of developing applications. As developers, I think we often forget this, or simply ignore it. In my career, I've learned a lot about web application security. However, I only recently learned and became familiar with the rapidly growing "appsec" industry.

I found a disconnect between what appsec consultants were selling and what I was developing. It seemed like appsec consultants were selling me fear, mostly because I thought my apps were secure. So I set out on a mission to learn more about web application security and penetration testing to see if my apps really were secure. This article is part of that mission, as are the previous articles I've written in this series.

When I first decided I wanted to do a talk on Webapp Security, I knew it would be more interesting if I showed the audience how to hack and fix an application. That's why I wrote it into my original proposal:

Webapp Security: Develop. Penetrate. Protect. Relax.
In this session, you'll learn how to implement authentication in your Java web applications using Spring Security, Apache Shiro and good ol' Java EE Container Managed Authentication. You'll also learn how to secure your REST API with OAuth and lock it down with SSL.

After learning how to develop authentication, I'll introduce you to OWASP, the OWASP Top 10, its Testing Guide and its Code Review Guide. From there, I'll discuss using WebGoat to verify your app is secure and commercial tools like webapp firewalls and accelerators.

At the time, I hadn't done much webapp pentesting. You can tell this from the fact that I mentioned WebGoat as the pentesting tool. From WebGoat's Project page:

WebGoat is a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application. For example, in one of the lessons the user must use SQL injection to steal fake credit card numbers. The application is a realistic teaching environment, providing users with hints and code to further explain the lesson.

What I really meant to say and use was Zed Attack Proxy, also known as OWASP ZAP. ZAP is a Java Desktop application that you setup as a proxy for your browser, then use to find vulnerabilities in your application. This article explains how you can use ZAP to pentest a web applications and fix its vulnerabilities.

The application I'll be using in this article is the Ajax Login application I've been using throughout this series. I think it's great that projects like Damn Vulnerable Web App and WebGoat exist, but I wanted to test one that I think is secure, rather than one I know is not secure. In this particular example, I'll be testing the Spring Security implementation, since that's the framework I most often use in my open source projects.

Zed Attack Proxy Tutorial

Download and Run the Application
Install and Configure ZAP
Perform a Scan
Fix Vulnerabilities
Summary

Download and Run the Application
To begin, download the application and expand it on your hard drive. This app is the completed version of the Ajax Login application referenced in Java Web Application Security - Part II: Spring Security Login Demo. You'll need Java 6 and Maven installed to run the app. Run it using mvn jetty:run and open http://localhost:8080 in your browser. You'll see it's a simple CRUD application for users and you need to login to do anything.

Install and Configure ZAP
The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. Download the latest version (I used 1.3.0) and install it on your system. After installing, launch the app and change the proxy port to 9000 (Tools > Options > Local Proxy). Next, configure your browser to proxy requests through port 9000 and allow localhost requests to be proxied. I used Firefox 4 (Preferences > Advanced > Network > Connection Settings). When finished, your proxy settings should look like the following screenshot:

Another option (instead of removing localhost) is to add an entry to your hosts file with your production domain name. This is what I've done for this demo.

127.0.0.1       demo.raibledesigns.com

I've also configured Apache to proxy requests to Jetty with the following mod_proxy settings in my httpd.conf:

<IfModule mod_proxy.c>
    ProxyRequests Off 
    ProxyPreserveHost Off 

    <VirtualHost *:80>
       ProxyPass  /  http://localhost:8080/
    </VirtualHost>

    <VirtualHost *:443>
        SSLEngine on
        SSLProxyEngine on
        SSLCertificateFile "/etc/apache2/ssl.key/server.crt"
        SSLCertificateKeyFile "/etc/apache2/ssl.key/server.key"

        ProxyPass  /  https://localhost:8443/
    </VirtualHost>
</IfModule>

Perform a Scan
Now you need to give ZAP some data to work with. Using Firefox, I navigated to http://demo.raibledesigns.com and browsed around a bit, listing users, added a new one and deleted an existing one. After doing this, I noticed a number of flags in the ZAP UI under Sites. I then right-clicked on each site (one for http and one for https) and selected Attack > Active Scan site. You should be able to do this from the "Active Scan" tab at the bottom of ZAP, but there's a bug when the URLs are the same. After doing this, I received a number of alerts, ranging from high (cross-site scripting) to low (password autocomplete). The screenshot below shows the various issues.

Now let's take a look at how to fix them.

Fix Vulnerabilities
One of the things not mentioned by the scan, but #1 in Seven Security (Mis)Configurations in Java web.xml Files, is Custom Error Pages Not Configured. Custom error pages are configured in this app, but error.jsp contains the following code:

<% if (exception != null) { %>
    <% exception.printStackTrace(new java.io.PrintWriter(out)); %>
<% } else { %>
    Please check your log files for further information.
<% } %>

Stack traces can be really useful to an attacker, so it's important to start by removing the above code from src/main/webapp/error.jsp.

The rest of the issues have to do with XSS, autocomplete, and cookies. Let's start with the easy ones. Fixing autocomplete is easy enough; simply changed the HTML in login.jsp and userform.jsp to have autocomplete="off" as part of the <form> tag.

Then modify web.xml so http-only and secure cookies are used. While you're at it, add session-timeout and tracking-mode as recommended by the aforementioned web.xml misconfigurations article.

<session-config>
    <session-timeout>15</session-timeout>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
    <tracking-mode>COOKIE</tracking-mode>
</session-config>

Next, modify Spring Security's Remember Me configuration so it uses secure cookies. To do this, add use-secure-cookies="true" to the <remember-me> element in security.xml.

<remember-me user-service-ref="userService" key="e37f4b31-0c45-11dd-bd0b-0800200c9a66"
             use-secure-cookie="true"/>

Unfortunately, Spring Security doesn't support HttpOnly cookies, but will in a future release.

The next issue to solve is disabling directory browsing. You can do this by copying Jetty's webdefault.xml (from the org.eclipse.jetty:jetty-webapp JAR) into src/test/resources and changing its "dirAllowed" <init-param> to false:

<servlet>
  <servlet-name>default</servlet-name>
  <servlet-class>org.mortbay.jetty.servlet.DefaultServlet</servlet-class>
  <init-param>
    <param-name>acceptRanges</param-name>
    <param-value>true</param-value>
  </init-param>
  <init-param>
    <param-name>dirAllowed</param-name>
    <param-value>false</param-value>
  </init-param>
  <init-param>

You'll also need to modify the plugin's configuration to point to this file by adding it to the <webAppConfig> section in pom.xml.

<configuration>
    <webAppConfig>
        <contextPath>/</contextPath>
        <defaultsDescriptor>src/test/resources/webdefault.xml</defaultsDescriptor>
    </webAppConfig>

Of course, if you're running in production you'll want to configure this in your server's settings rather than in your pom.xml file.

Next, I set out to fix secure page browser cache issues. I had the following settings in my SiteMesh decorator:

<meta http-equiv="Cache-Control" content="no-store"/>
<meta http-equiv="Pragma" content="no-cache"/>

However, according to ZAP, the first meta tag should have "no-cache" instead of "no-store", so I changed it to "no-cache".

After making all these changes, I created a new ZAP session and ran an active scan on both sites again. Below are the results:

I believe the first issue (parameter tampering) is because I show the error page when a duplicate user exists. To fix this, I changed UserFormController so it catches a UserExistsException and sends the user back to the form.

try {
    userManager.saveUser(user);
} catch (UserExistsException uex) {
    result.addError(new ObjectError("user", uex.getMessage()));
    return "userform";
}

However, this still doesn't seem to cause the alert to go away. This is likely because I'm not filtering/escaping HTML when it's first submitted. I believe the best solution for this would be to use something like OWASP's ESAPI to filter parameter values. However, I was unable to find integration with Spring MVC's data binding, so I decided not to try and fix this vulnerability.

Finally, I tried to disable jsessionid in URLs using suggestions from Stack Overflow. The previous setting in web.xml (<tracking-mode>COOKIE</tracking-mode>) should do this, but it doesn't seem to work with Jetty 8. The other issues (secure page browser cache, HttpOnly cookies and secure cookies), I was unable to solve. The last two are issues caused by Spring Security as far as I can tell.

Summary
In this article, I've shown you how to pentest a web application using Firefox and OWASP's Zed Attack Proxy (ZAP). I found ZAP to be a nice tool for figuring out vulnerabilities, but it'd be nice if it had a "retest" feature to see if you fixed an issue for a particular URL. It does have a "resend" feature, but running it didn't seem to clear alerts after I'd fixed them.

The issues I wasn't able to solve seemed to be mostly related to frameworks (e.g. Spring Security and HttpOnly cookies) or servers (Jetty not using cookies for tracking). My suspicion is the Jetty issues are because it doesn't support Servlet 3 as well as it advertises. I believe this is fair; I am using a milestone release after all. I tried scanning http://demo.raibledesigns.com/ajax-login (which runs on Tomcat 7 at Contegix) and confirmed that no jsessionid exists.

Hopefully this article has helped you understand how to figure out security vulnerabilities in your web applications. I believe ZAP will continue to get more popular as developers become aware of it. If you feel ambitious and want to try and solve all of the issues in my Ajax Login application, feel free to fork it on GitHub.

If you're interested in talking more about Webapp Security, please leave a comment, meet me at Jazoon later this week or let's talk in July at Über Conf.

Java Web Application Security - Part IV: Programmatic Login APIs

2011-06-06T21:44:09-06:00

Over the last month, I've posted a number of articles on implementing authentication with Java EE 6, Spring Security and Apache Shiro. One of the things I demonstrated in my live demos (at Utah's JUG Meetings) was programmatic authentication. I left this out of my screencasts and previous tutorials because I thought it'd fit better in a comparison article.

In this article, I'd like to show you how you can programmatically login to an application using the aforementioned security frameworks. To do this, I'll be using my ajax-login application that I wrote for Implementing Ajax Authentication using jQuery, Spring Security and HTTPS.

To begin, I implemented a LoginController as a Spring MVC Controller that returns JSON.

package org.appfuse.examples.webapp.security;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
@RequestMapping("/api/login.json")
public class LoginController {

    @Autowired
    LoginService loginService;

    @RequestMapping(method = RequestMethod.GET)
    @ResponseBody
    public LoginStatus getStatus() {
        return loginService.getStatus();
    }

    @RequestMapping(method = RequestMethod.POST)
    @ResponseBody
    public LoginStatus login(@RequestParam("j_username") String username,
                             @RequestParam("j_password") String password) {

        return loginService.login(username, password);
    }
}

This controller delegates its logic to a LoginService interface.

package org.appfuse.examples.webapp.security;

public interface LoginService {

  LoginStatus getStatus();

  LoginStatus login(String username, String password);
}

The Client
The client for this controller is the same as mentioned in my previous article, but I'll post it again for your convenience. I used jQuery and jQuery UI to implement a dialog that opens the login page on the same page rather than redirecting to the login page. The "#demo" locator refers to a button in the page.

var dialog = $('<div></div>');

$(document).ready(function() {
    $.get('/login?ajax=true', function(data) {
        dialog.html(data);
        dialog.dialog({
            autoOpen: false,
	       title: 'Authentication Required'
        });
    });

    $('#demo').click(function() {
      dialog.dialog('open');
      // prevent the default action, e.g., following a link
      return false;
    });
});

The login page then has the following JavaScript to add a click handler to the "login" button that submits the request securely to the LoginController.

var getHost = function() {
    var port = (window.location.port == "8080") ? ":8443" : "";
    return ((secure) ? 'https://' : 'http://') + window.location.hostname + port;
};

var loginFailed = function(data, status) {
    $(".error").remove();
    $('#username-label').before('Login failed, please try again.');
};

$("#login").live('click', function(e) {
    e.preventDefault();
    $.ajax({url: getHost() + "${ctx}/api/login.json",
        type: "POST",
        beforeSend: function(xhr) {
            xhr.withCredentials = true;
        },
        data: $("#loginForm").serialize(),
        success: function(data, status) {
            if (data.loggedIn) {
                // success
                dialog.dialog('close');
                location.href = getHost() + '${ctx}/users';
            } else {
                loginFailed(data);
            }
        },
        error: loginFailed
    });
});

The biggest secret to making this all work (the HTTP -> HTTPS communication, which is considered cross-domain), is the window.name Transport and the jQuery plugin that implements it. To make this plugin work with Firefox 3.6, I had to implement a Filter that adds Access-Control headers.

public class OptionsHeadersFilter implements Filter {

    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;

        response.setHeader("Access-Control-Allow-Origin", "http://" + req.getServerName());
        response.setHeader("Access-Control-Allow-Methods", "GET,POST");
        response.setHeader("Access-Control-Max-Age", "360");
        response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
        response.setHeader("Access-Control-Allow-Credentials", "true");

        chain.doFilter(req, res);
    }

    public void init(FilterConfig filterConfig) {
    }

    public void destroy() {
    }
}

Java EE 6 LoginService
Java EE 6 has a few new methods in HttpServletRequest:

authenticate(response)
login(user, pass)
logout()

In this example, I'll use the new login(username, password) method. The hardest part about getting this working was finding the right Maven dependency. At first, I tried the one that seemed to make the most sense:

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-web-api</artifactId>
    <version>6.0</version>
</dependency>

Unfortunately, this resulted in a strange error that means the dependency has the interfaces, but not the implementation classes. I ended up using GlassFish's dependency instead (thanks to Stack Overflow for the tip).

<dependency>
    <groupId>org.glassfish</groupId>
    <artifactId>javax.servlet</artifactId>
    <version>3.0</version>
    <scope>provided</scope>
</dependency>

Since Servlet 3.0 doesn't appear to be in Maven Central, I had to add the GlassFish Repository to my pom.xml's <repositories> element.

<repository>
    <id>glassfish-repo</id>
    <url>http://download.java.net/maven/glassfish</url>
</repository>

After that, it was easy to implement the LoginService interface with a JavaEELoginService class:

package org.appfuse.examples.webapp.security;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;

@Service("javaeeLoginService")
public class JavaEELoginService implements LoginService {
    private Log log = LogFactory.getLog(JavaEELoginService.class);

    @Autowired
    HttpServletRequest request;

    public LoginStatus getStatus() {
        if (request.getRemoteUser() != null) {
            return new LoginStatus(true, request.getRemoteUser());
        } else {
            return new LoginStatus(false, null);
        }
    }

    @Override
    public LoginStatus login(String username, String password) {
        try {
            if (request.getRemoteUser() == null) {
                request.login(username, password);
                log.debug("Login succeeded!");
            }
            return new LoginStatus(true, request.getRemoteUser());
        } catch (ServletException e) {
            e.printStackTrace();
            return new LoginStatus(false, null);
        }
    }
}

I tried to use this with "mvn jetty:run" (with version 8.0.0.M2 of the jetty-maven-plugin), but I got the following error:

javax.servlet.ServletException
        at org.eclipse.jetty.server.Request.login(Request.java:1927)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.beans.factory.support.AutowireUtils$ObjectFactoryDelegatingInvocationHandler.invoke(AutowireUtils.java:178)
        at $Proxy52.login(Unknown Source)
        at org.appfuse.examples.webapp.security.JavaEELoginService.login(JavaEELoginService.java:30)

This lead me to believe that Servlet 3 is not quite implemented, so I tried it with Tomcat 7.0.8. To support SSL and container-managed authentication, I had to create a certificate keystore and uncomment the SSL Connector in $CATALINA_HOME/conf/server.xml. I also had to add an "admin" user with roles="ROLE_ADMIN" to $CATALINA_HOME/conf/tomcat-users.xml.

<user username="admin" password="admin" roles="ROLE_ADMIN"/>

With Tomcat 7, I was able to login successfully, proven by the following logging.

DEBUG - JavaEELoginService.login(31) | Login succeeded!

However, in the UI, I still got a "Login failed, please try again." message. Recalling that I had some issues with ports previous, I configured Apache to proxy the default http/https ports to 8080/8443 and tried again. This time it worked!

Spring Security LoginService
Spring Security offers a programmatic API and I was able to implement its LoginService as follows:

package org.appfuse.examples.webapp.security;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.appfuse.model.User;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.security.authentication.AuthenticationManager;
import org.springframework.security.authentication.BadCredentialsException;
import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.stereotype.Service;

@Service("springLoginService")
public class SpringSecurityLoginService implements LoginService {
    private Log log = LogFactory.getLog(SpringSecurityLoginService.class);

    @Autowired(required = false)
    @Qualifier("authenticationManager")
    AuthenticationManager authenticationManager;

    public LoginStatus getStatus() {
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        if (auth != null && !auth.getName().equals("anonymousUser") && auth.isAuthenticated()) {
            return new LoginStatus(true, auth.getName());
        } else {
            return new LoginStatus(false, null);
        }
    }

    public LoginStatus login(String username, String password) {
        UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(username, password);
        User details = new User(username);
        token.setDetails(details);

        try {
            Authentication auth = authenticationManager.authenticate(token);
            log.debug("Login succeeded!");
            SecurityContextHolder.getContext().setAuthentication(auth);
            return new LoginStatus(auth.isAuthenticated(), auth.getName());
        } catch (BadCredentialsException e) {
            return new LoginStatus(false, null);
        }
    }
}

I then modified the LoginService dependency in LoginController so this implementation would be used.

@Autowired
@Qualifier("springLoginService")
LoginService loginService;

Since Spring's API doesn't depend on Servlet 3, I tried it in Jetty using "mvn jetty:run". Of course, I modified my web.xml accordingly for Spring Security before doing so. Interestingly enough, I found that the my SpringSecurityLoginService seemed to work:

DEBUG - SpringSecurityLoginService.login(39) | Login succeeded!

But in the UI, the login failed with a "Login failed, please try again." message. Using the standard ports with Apache in front of Jetty solved this issue.

Apache Shiro LoginService
Apache Shiro is nice enough to offer a programmatic API as well. I was able to implement a ShiroLoginService as follows:

package org.appfuse.examples.webapp.security;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.shiro.SecurityUtils;
import org.apache.shiro.authc.AuthenticationException;
import org.apache.shiro.authc.UsernamePasswordToken;
import org.apache.shiro.subject.Subject;
import org.springframework.stereotype.Service;

@Service("shiroLoginService")
public class ShiroLoginService implements LoginService {
    private Log log = LogFactory.getLog(ShiroLoginService.class);

    public LoginStatus getStatus() {
        Subject currentUser = SecurityUtils.getSubject();
        if (currentUser.isAuthenticated()) {
            return new LoginStatus(true, currentUser.getPrincipal().toString());
        } else {
            return new LoginStatus(false, null);
        }
    }

    public LoginStatus login(String username, String password) {
        if (!getStatus().isLoggedIn()) {
            UsernamePasswordToken token = new UsernamePasswordToken(username, password);
            Subject currentUser = SecurityUtils.getSubject();
            try {
                currentUser.login(token);
                log.debug("Login succeeded!");
                return new LoginStatus(currentUser.isAuthenticated(),
                        currentUser.getPrincipal().toString());
            } catch (AuthenticationException e) {
                return new LoginStatus(false, null);
            }

        } else {
            return getStatus();
        }
    }
}

Then I modified the LoginService dependency in LoginController so this implementation would be used.

@Autowired
@Qualifier("shiroLoginService")
LoginService loginService;

Next, I modified my web.xml for Apache Shiro and tried "mvn jetty:run". Again, the login appeared to succeed (based on log messages) on the server, but failed in the UI. When using http://localhost instead of http://localhost:8080, everything worked fine.

Summary
This article has shown you how you can programmatically login using Java EE 6, Spring Security and Apache Shiro. Before Java EE 6 (and Servlet 3), there was no API to programmatically login, so this is a welcome addition. The fact that my Ajax login example didn't work when ports differed is because of browsers' same origin policy, which specifies the ports have to be the same. Specifying no ports (the defaults), seems to be the loophole.

On a related note, I've discovered some interesting articles recently from the AppSec Blog.

The 2nd article has an interesting paragraph:

... there's Apache Shiro (FKA JSecurity and then later as Apache Ki), another secure framework for Java apps. Although it looks simpler to use and understand than ESAPI and covers most of the main security bases (authentication, authorization, session management and encryption), it doesn't help take care of important functions like input validation and output encoding. And Spring users have Spring Security (Acegi) a comprehensive, but heavyweight authorization and authentication framework.

So according to this blog, the security frameworks discussed here aren't the best.

The most comprehensive, up-to-date choice for Java developers is OWASP's ESAPI Enterprise Security API especially now that the 2.0 release has just come out.

I haven't heard of many organizations adopting ESAPI over Java EE 6, Spring Security or Apache Shiro, but maybe I'm wrong. Is ESAPI something that's being used out there by companies?

Java Web Application Security - Part III: Apache Shiro Login Demo

2011-05-26T16:43:22-06:00

A couple weeks ago, I wrote a tutorial on how to implement security with Spring Security. The week prior, I wrote a similar tutorial for Java EE 6. This week, I'd like to show you how to implement the same features using Apache Shiro. As I mentioned in previous articles, I'm writing this because I told the audience at April's UJUG that I would publish screencasts of the demos.

Today, I've finished the third screencast showing how to implement security with Apache Shiro. Below is the presentation (with the screencast embedded on slide 22) as well as a step-by-step tutorial.

* You can also watch the screencast on YouTube or download the presentation PDF.

Download and Run the Application
Implement Basic Authentication
Force SSL
Implement Form-based Authentication
Store Users in a Database
Summary

Download and Run the Application
To begin, download the application you'll be implementing security in. This app is a stripped-down version of the Ajax Login application I wrote for my article on Implementing Ajax Authentication using jQuery, Spring Security and HTTPS. You'll need Java 6 and Maven installed to run the app. Run it using mvn jetty:run and open http://localhost:8080 in your browser. You'll see it's a simple CRUD application for users and there's no login required to add or delete users.

Implement Basic Authentication
The first step is to protect the list screen so people have to login to view users. To do this, you'll need to create a shiro.ini file Shiro's configuration. Create src/main/resources/shiro.ini and populate it with the contents below:

[main]

[users]
admin = admin, ROLE_ADMIN

[roles]
ROLE_ADMIN = *

[urls]
/app/users = authcBasic

You can see this file has four sections and is pretty simple to read and understand. For more information about what each section is for, check out Shiro's configuration documentation.

Next, open src/main/webapp/WEB-INF/web.xml and add Shiro's IniShiroFilter:

<filter>
    <filter-name>securityFilter</filter-name>
    <filter-class>org.apache.shiro.web.servlet.IniShiroFilter</filter-class>
    <!-- no init-param means load the INI config from classpath:shiro.ini -->
</filter>

And add its filter-mapping just after the rewriteFilter in the filter-mappings section (order is important!):

<filter-mapping>
    <filter-name>rewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>securityFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
</filter-mapping>

Then add Shiro's core and web dependencies to your pom.xml:

<dependency>
    <groupId>org.apache.shiro</groupId>
    <artifactId>shiro-core</artifactId>
    <version>1.1.0</version>
</dependency>
<dependency>
    <groupId>org.apache.shiro</groupId>
    <artifactId>shiro-web</artifactId>
    <version>1.1.0</version>
</dependency>

At this point, if you restart Jetty (Ctrl+C and jetty:run again), you should be prompted to login when you click on the "Users" tab. Enter admin/admin to login. Apache Shiro is easier to configure than Spring Security out-of-the-box, mostly because it doesn't require XML.

After logging in, you can try to logout by clicking the "Logout" link in the top-right corner. This calls a LogoutController with the following code that logs the user out.

public void logout(HttpServletResponse response) throws ServletException, IOException {
    request.getSession().invalidate();
    response.sendRedirect(request.getContextPath()); 
}

NOTE: Shiro doesn't currently have a way to logout with its API. However, it will be added in the 1.2 release.

You'll notice that clicking this link doesn't log you out, even though the session is invalidated. The only way to logout with basic authentication is to close the browser. In order to get the ability to logout, as well as to have more control over the look-and-feel of the login, you can implement form-based authentication. Before you implement form-based authentication, I'd like to show you how easy it is to force SSL with Apache Shiro.

Force SSL
Apache Shiro allows you to force SSL on a URL by simply adding "ssl[port]" to a URL in the [urls] section. If you don't specify the port, it will use the default port (443). I'm not sure if it allows you to switch back to http like Spring Security's requires-channel, but I don't think it does. Modify the URLs section of your shiro.ini to have the following:

[urls]
/app/users = ssl[8443],authc

In order for this to work, you have to configure Jetty to listen on an SSL port. Add the following just after the jetty-maven-plugin's </webAppConfig> element in your pom.xml:

<connectors>
    <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
        <forwarded>true</forwarded>
        <port>8080</port>
    </connector>
    <connector implementation="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
        <forwarded>true</forwarded>
        <port>8443</port>
        <maxIdleTime>60000</maxIdleTime>
        <keystore>${project.build.directory}/ssl.keystore</keystore>
        <password>appfuse</password>
        <keyPassword>appfuse</keyPassword>
    </connector>
</connectors>

The keystore must be generated for Jetty to start successfully, so add the keytool-maven-plugin just above the jetty-maven-plugin in pom.xml.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>keytool-maven-plugin</artifactId>
    <version>1.0</version>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <id>clean</id>
            <goals>
                <goal>clean</goal>
            </goals>
        </execution>
        <execution>
            <phase>generate-resources</phase>
            <id>genkey</id>
            <goals>
                <goal>genkey</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>${project.build.directory}/ssl.keystore</keystore>
        <dname>cn=localhost</dname>
        <keypass>appfuse</keypass>
        <storepass>appfuse</storepass>
        <alias>appfuse</alias>
        <keyalg>RSA</keyalg>
    </configuration>
</plugin>

Now if you restart Jetty, go to http://localhost:8080 and click on the "Users" tab, you'll be prompted to accept the Untrusted Certificate and then redirected to https://localhost:8443/users after logging in.

Now let's look at how to have more control over the look-and-feel of the login screen, as well as how to make logout work with form-based authentication.

Implement Form-based Authentication
To change from basic to form-based authentication, you simply have to add a few lines to shiro.ini. First of all, since I'd rather not change the name of the input elements in login.jsp, override the default names in the [main] section:

# name of request parameter with username; if not present filter assumes 'username'
authc.usernameParam = j_username
# name of request parameter with password; if not present filter assumes 'password'
authc.passwordParam = j_password
authc.failureKeyAttribute = shiroLoginFailure

Then change the [urls] section to filter on login.jsp and use "authc" instead of "authcBasic":

[urls]
# The /login.jsp is not restricted to authenticated users (otherwise no one could log in!), but
# the 'authc' filter must still be specified for it so it can process that url's
# login submissions. It is 'smart' enough to allow those requests through as specified by the
# shiro.loginUrl above.
/login.jsp = authc
/app/users = ssl[8443],authc

Then change login.jsp so the form's action is blank (causing it to submit to itself) instead of j_security_check:

<form action="" id="loginForm" method="post">

Now, restart Jetty and you should be prompted to login with this JSP instead of the basic authentication dialog.

Store Users in a Database
To store your users in a database instead of file, you'll need to add a few settings to shiro.ini to define your database and tables to use. Open src/main/resources/shiro.ini and add the following lines under the [main] section.

jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm
#jdbcRealm.permissionsLookupEnabled=false
# If not filled, subclasses of JdbcRealm assume "select password from users where username = ?"
jdbcRealm.authenticationQuery = select user_pass from users where user_name = ?
# If not filled, subclasses of JdbcRealm assume "select role_name from user_roles where username = ?"
jdbcRealm.userRolesQuery = select role_name from users_roles where user_name = ?

ds = com.mysql.jdbc.jdbc2.optional.MysqlDataSource
ds.serverName = localhost
ds.user = root
ds.databaseName = appfuse
jdbcRealm.dataSource = $ds

This configuration is similar to what I did with the Java EE 6 tutorial where I'm pointing to a database other than the H2 instance that's used by the application. I believe Shiro can talk to a DAO like Spring Security, but I have yet to explore that option.

While you're at it, add the following lines to enable password encryption.

sha256Matcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher
jdbcRealm.credentialsMatcher = $sha256Matcher

You'll need to install MySQL for this to work. After installing it, you should be able to create an "appfuse" database using the following command:

mysql -u root -p -e 'create database appfuse'

Then create the tables necessary and populate it with an 'admin' user. Login using "mysql -u root -p appfuse" and execute the following SQL statements:

create table users (
  user_name         varchar(30) not null primary key,
  user_pass         varchar(100) not null
);

create table user_roles (
  user_name         varchar(30) not null,
  role_name         varchar(30) not null,
  primary key (user_name, role_name)
);

insert into users values ('admin', '22f256eca1f336a97eef2b260773cb0d81d900c208ff26e94410d292d605fed8');
insert into user_roles values ('admin', 'ROLE_ADMIN');

Now if you restart Jetty, you should be able to login with admin/adminjdbc and view the list of users.

Summary
In this tutorial, you learned how to implement authentication using Apache Shiro 1.1.0. I don't have a lot of experience with Apache Shiro, but I was able to get the basics working without too much effort. This tutorial doesn't show how to do Remember Me because I couldn't figure it out in 5 minutes, which means I have 5 more minutes before it fails the 10-minute test.

Shiro was formerly named JSecurity and has been an Apache project for less than a year. It seems to be more targeted towards non-web use, so its certainly something to look at if you're more interested in cryptography or non-web apps. I think there's a good chance this project will continue to grow and be used more as more developers learn about it. The Apache brand certainly doesn't hurt.

I didn't include a slide about the limitations I found with Shiro, mostly because I haven't used it much. I've used Java EE and Spring Security for several years. The main limitation I found was the lack of documentation, but I've heard it's improving rapidly.

In the next couple weeks, I'll post a Part IV on implementing programmatic login using the APIs of Java EE 6, Spring Security and Apache Shiro. I'll be presenting this topic at Jazoon as well as the long-form version (with hacking) at ÜberConf. Hopefully I'll see you at one of those conferences.

Update: Thanks to help from Les Hazlewood, I've figured out how to implement Remember Me with Apache Shiro. In the [urls] section of shiro.ini, the second url (shown below) says to Shiro "In order to visit the /app/users URL, you must be connecting via SSL on port 8443 and you must also be authenticated."

/app/users = ssl[8443],authc

Remembered users are not authenticated because their identity hasn't been proven during the current session. What I want Shiro to say is "In order to visit the /app/users URL, you must be connecting via SSL on 8443 and you must also be a known user. If you're not, you should login first." Where a known user is someone who has a recognized identity and has either authenticated during the current session or is known via RememberMe from a previous session. The documentation gives a good example with Amazon.com for why Shiro makes this distinction. It allows more control (usually necessary), but you can relax the control as you see fit.

So, to relax my configuration a bit to match what I want (known users), I updated shiro.ini's [urls] section to be as follows:

/app/users = ssl[8443],user

The key is that the /app/users url is now protected with the more relaxed user filter instead of the authc filter. However, you would typically want an account profile page (or credit card information page, or similar) protected with the authc filter instead to guarantee proof of identity for those sensitive operations.

Java Web Application Security - Part II: Spring Security Login Demo

2011-05-13T09:20:51-06:00

Last week, I wrote a tutorial on how to implement Security in Java EE 6. This week, I'd like to show you how to implement the same features using Spring Security. Before I begin, I'd like to explain my reason for writing this article.

Last month, I presented a talk on Java Web Application Security at the Utah JUG (UJUG). As part of that presentation, I did a number of demos about how to implement security with Java EE 6, Spring Security and Apache Shiro. I told the audience that I would post the presentation and was planning on recording screencasts of the various demos so the online version of the presentation would make more sense.

Today, I've finished the second screencast showing how to implement security with Spring Security. Below is the presentation (with the screencast embedded on slide 16) as well as a step-by-step tutorial.

* You can also watch the screencast on YouTube or download the presentation PDF.

Download and Run the Application
Implement Basic Authentication
Force SSL
Implement Form-based Authentication
Add Remember Me
Store Users in a Database
Summary

Implement Basic Authentication
The first step is to protect the list screen so people have to login to view users. To do this, you'll need to create a Spring context file that contains Spring Security's configuration. Create src/main/webapp/WEB-INF/security.xml and populate it with the contents below:

  <?xml version="1.0" encoding="UTF-8"?>
  <beans:beans xmlns="http://www.springframework.org/schema/security"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:beans="http://www.springframework.org/schema/beans"
               xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">

      <!-- New in Spring Security 3.1 -->
      <!-- <http pattern="/css/**" security="none"/> -->

      <http auto-config="true">
          <intercept-url pattern="/app/users" access="ROLE_USER,ROLE_ADMIN"/>
          <http-basic/>
      </http>

      <authentication-manager alias="authenticationManager">
          <authentication-provider>
              <password-encoder hash="sha"/>
              <user-service>
                  <user name="user" password="12dea96fec20593566ab75692c9949596833adc9" authorities="ROLE_USER"/>
                  <user name="admin" password="d033e22ae348aeb5660fc2140aec35850c4da997" authorities="ROLE_ADMIN"/>
              </user-service>
          </authentication-provider>
      </authentication-manager>

      <!-- Override userSecurityAdvice bean in appfuse-service to allow any role to update a user. -->
      <beans:bean id="userSecurityAdvice" class="org.appfuse.examples.webapp.security.UserSecurityAdvice"/>
  </beans:beans>

The last bean, userSecurityAdvice, is an aspect that's needed to override some behavior in AppFuse. You won't need this normally when implementing Spring Security.

Next, open src/main/webapp/WEB-INF/web.xml and add Spring's DelegatingFilterProxy:

<filter>
    <filter-name>securityFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    <init-param>
        <param-name>targetBeanName</param-name>
        <param-value>springSecurityFilterChain</param-value>
    </init-param>
</filter>

And add its filter-mapping just after the rewriteFilter in the filter-mappings section (order is important!):

<filter-mapping>
    <filter-name>rewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>securityFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
</filter-mapping>

You don't need to add any dependencies in your pom.xml is because this project depends on AppFuse, which already contains these dependencies.

At this point, if you restart Jetty (Ctrl+C and jetty:run again), you should be prompted to login when you click on the "Users" tab. Enter admin/admin to login. Spring Security is a bit easier to configure than Java EE 6 out-of-the-box, mostly because it doesn't require you to configure your container.

After logging in, you can try to logout by clicking the "Logout" link in the top-right corner. This calls a LogoutController with the following code that logs the user out.

public void logout(HttpServletResponse response) throws ServletException, IOException {
    request.getSession().invalidate();
    response.sendRedirect(request.getContextPath()); 
}

NOTE: Spring Security has a way to configure "logout" to match a URL and get rid of a class like LogoutController. Since it was already in the project, I don't cover that in this tutorial.

Force SSL
Spring Security allows you to switch between secure (https) and non-secure (http) protocols using a simple requires-channel attribute on the <intercept-url> element. Possible values are "http", "https" and "any". Add requires-channel="https" to your security.xml file:

<intercept-url pattern="/app/users" access="ROLE_USER,ROLE_ADMIN" requires-channel="https"/>

In order for this to work, you have to configure Jetty to listen on an SSL port. Add the following just after the jetty-maven-plugin's </webAppConfig> element in your pom.xml:

<connectors>
    <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
        <forwarded>true</forwarded>
        <port>8080</port>
    </connector>
    <connector implementation="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
        <forwarded>true</forwarded>
        <port>8443</port>
        <maxIdleTime>60000</maxIdleTime>
        <keystore>${project.build.directory}/ssl.keystore</keystore>
        <password>appfuse</password>
        <keyPassword>appfuse</keyPassword>
    </connector>
</connectors>

The keystore must be generated for Jetty to start successfully, so add the keytool-maven-plugin just above the jetty-maven-plugin in pom.xml.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>keytool-maven-plugin</artifactId>
    <version>1.0</version>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <id>clean</id>
            <goals>
                <goal>clean</goal>
            </goals>
        </execution>
        <execution>
            <phase>generate-resources</phase>
            <id>genkey</id>
            <goals>
                <goal>genkey</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>${project.build.directory}/ssl.keystore</keystore>
        <dname>cn=localhost</dname>
        <keypass>appfuse</keypass>
        <storepass>appfuse</storepass>
        <alias>appfuse</alias>
        <keyalg>RSA</keyalg>
    </configuration>
</plugin>

You can switch between http and https protocols. With Java EE, you can only force https. You have to write a custom filter to switch back to http.
Redirecting to https actually works. With Java EE (on Jetty at least), a 403 is returned instead of redirecting the request.

Now let's look at how to have more control over the look-and-feel of the login screen, as well as how to make logout work with form-based authentication.

Implement Form-based Authentication
To change from basic to form-based authentication, you simply have to add a <form-login> element in security.xml's <http> element:

<http auto-config="true">
    <intercept-url pattern="/app/users" access="ROLE_USER,ROLE_ADMIN" requires-channel="https"/>
    <form-login login-page="/login" authentication-failure-url="/login?error=true"
                login-processing-url="/j_security_check"/>
    <http-basic/>
</http>

You can leave the <http-basic> element since Spring Security is smart enough to serve up the form for browsers and use Basic Authentication for clients such as web services. The login.jsp page (that /login forwards to) already exists in the project, in the src/main/webapp directory. The forwarding is done by the UrlRewriteFilter with the following configuration in src/main/webapp/WEB-INF/urlrewrite.xml.

<rule>
    <from>/login</from>
    <to>/login.jsp</to>
</rule>

This JSP has 3 important elements: 1) a form that submits to "/j_security_check", 2) an input element named "j_username" and 3) an input element named "j_password". If you restart Jetty, you'll now be prompted to login with this JSP instead of the basic authentication dialog.

Add Remember Me
Remember Me is a feature you see in many web applications today. It's usually a checkbox on the login form that allows you to auto-login the next time you visit a site. This feature doesn't exist in Java EE security, but it does exist in Spring Security. To enable it, add the following just below <form-login> in security.xml:

<remember-me user-service-ref="userDao" key="e37f4b31-0c45-11dd-bd0b-0800200c9a66"/>

Next, open src/main/webapp/login.jsp and change the name of the "remember me" checkbox to be _spring_security_remember_me:

<input type="checkbox" name="_spring_security_remember_me" id="rememberMe"/>

After making these changes, you should be able to restart Jetty, go to http://localhost:8080/users, enter admin/adminjdbc, check the Remember Me checkbox and login. Then close your browser, and repeat the process. This time, you won't be prompted to login. For more information on this feature, see Spring Security's Remember Me documentation.

While storing usernames and passwords in a file is convenient for demos, it's not very real-world-ish. The next section shows you how to configure Spring Security to use a database for its user store.

Store Users in a Database
To store your users in a database instead of file, you'll need to add a user-service-ref attribute to the <authentication-provider> element. You can also delete the <user-service> element.

<authentication-manager alias="authenticationManager">
    <authentication-provider user-service-ref="userDao">
        <password-encoder hash="sha"/>
    </authentication-provider>
</authentication-manager>

The "userDao" bean is provided by AppFuse and its UserDaoHibernate.java class. This class implements Spring Security's UserDetailsService interface. With Java EE, I had to configure a database connection and make sure the JDBC Driver was in my container's classpath. With Spring Security, you can talk to the database you already have configured in your application.

Of course, you could do this with Java EE too. One thing I neglected to show in my last tutorial was that 1) the app uses H2 and 2) I had to configure Java EE's database to be MySQL. This was because when I tried to access my H2 instance, I got an error about two threads trying to access it at once.

2011-05-13 08:47:29.081:WARN::UserRealm Java EE Login could not connect to database; will try later
org.h2.jdbc.JdbcSQLException: Database may be already in use: "Locked by another process". 
        Possible solutions: close all other connection(s); use the server mode [90020-154]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:327)
	at org.h2.message.DbException.get(DbException.java:167)
	at org.h2.message.DbException.get(DbException.java:144)
	at org.h2.store.FileLock.getExceptionAlreadyInUse(FileLock.java:443)
	at org.h2.store.FileLock.lockFile(FileLock.java:338)
	at org.h2.store.FileLock.lock(FileLock.java:134)
	at org.h2.engine.Database.open(Database.java:535)
	at org.h2.engine.Database.openDatabase(Database.java:218)

The password for the "admin" user is configured in src/test/resources/sample-data.xml and it's loaded by DbUnit before the application starts. You can view your pom.xml and the dbunit-maven-plugin's configuration if you're interested in learning how this is done. The password is currently configured to "adminjdbc", but you can reset it by generating a new password and modifying sample-data.xml.

Now if you restart Jetty, you should be able to login with admin/adminjdbc and view the list of users.

Summary
In this tutorial, you learned how to implement authentication using Spring Security 3.0.5. In addition to the basic XML configuration, Spring Security also provides a AOP support and annotations you can use to secure methods. It also has many more features than standard Java EE Security. In my opinion, it's the most mature security framework we have in Java today. Currently, I think its reference documentation is the best place to learn more.

There are a few limitations I found with Spring Security:

The authentication mechanism (file, database, ldap, etc.) is contained in the WAR
Securing methods only works on Spring beans
Remember Me doesn't work in my screencast (because I forgot to rename the checkbox in login.jsp)

Of course, you can configure Spring to load its configuration from outside the WAR (e.g. a file or JNDI), but it's not as easy as including the configuration in your app.

In the next couple weeks, I'll post Part III of this series, where I'll show you how to implement this same set of features using Apache Shiro. In the meantime, please let me know if you have any questions.

I created the screencasts with Camtasia. For small screens, and embedding in the presentation, I created it at 50% and used the SmartFocus feature to zoom in and out during the demo. For larger screens, I published another screencast at 100%, in HD. If you have a preference for which screencast is better, I'd love to hear about it.

Java Web Application Security - Part I: Java EE 6 Login Demo

2011-05-05T16:58:00-06:00

Back in February, I wrote about my upcoming conferences:

In addition to Vegas and Poland, there's a couple other events I might speak at in the next few months: the Utah Java Users Group (possibly in April), Jazoon and ÜberConf (if my proposals are accepted). For these events, I'm hoping to present the following talk:

Fast forward a couple months and I'm happy to say that I've completed my talk at the Utah JUG and it's been accepted at Jazoon and Über Conf. For this talk, I created a presentation that primarily consists of demos implementing basic, form and Ajax authentication using Java EE 6, Spring Security and Apache Shiro. In the process of creating the demos, I learned (or re-educated myself) how to do a number of things in all 3 frameworks:

Implement Basic Authentication
Implement Form-based Authentication
Implement Ajax HTTP -> HTTPS Authentication (with programmatic APIs)
Force SSL for certain URLs
Implement a file-based store of users and passwords (in Jetty/Maven and Tomcat standalone)
Implement a database store of users and passwords (in Jetty/Maven and Tomcat standalone)
Encrypt Passwords
Secure methods with annotations

For the demos, I showed the audience how to do almost all of these, but skipped Tomcat standalone and securing methods in the interest of time. In July, when I do this talk at ÜberConf, I plan on adding 1) hacking the app (to show security holes) and 2) fixing it to protect it against vulnerabilities.

I told the audience at UJUG that I would post the presentation and was planning on recording screencasts of the various demos so the online version of the presentation would make more sense. Today, I've finished the first screencast showing how to implement security with Java EE 6. Below is the presentation (with the screencast embedded on slide 10) as well as a step-by-step tutorial.

* You can also watch the screencast on YouTube or download the presentation PDF.

Implement Basic Authentication
The first step is to protect the list screen so people have to login to view users. To do this, add the following to the bottom of src/main/webapp/WEB-INF/web.xml:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>users</web-resource-name>
        <url-pattern>/users</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>ROLE_ADMIN</role-name>
    </auth-constraint>
</security-constraint>

<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Java EE Login</realm-name>
</login-config>

<security-role>
    <role-name>ROLE_ADMIN</role-name>
</security-role>

At this point, if you restart Jetty (Ctrl+C and jetty:run again), you'll get an error about a missing LoginService. This happens because Jetty doesn't know where the "Java EE Login" realm is located. Add the following to pom.xml, just after </webAppConfig> in the Jetty plugin's configuration.

<loginServices>
    <loginService implementation="org.eclipse.jetty.security.HashLoginService">
        <name>Java EE Login</name>
        <config>${basedir}/src/test/resources/realm.properties</config>
    </loginService>
</loginServices>

The realm.properties file already exists in the project and contains user names and passwords. Start the app again using mvn jetty:run and you should be prompted to login when you click on the "Users" tab. Enter admin/admin to login.

After logging in, you can try to logout by clicking the "Logout" link in the top-right corner. This calls a LogoutController with the following code that logs the user out.

public void logout(HttpServletResponse response) throws ServletException, IOException {
    request.getSession().invalidate();
    response.sendRedirect(request.getContextPath());
}

Implement Form-based Authentication
To change from basic to form-based authentication, you simply have to replace the <login-config> in your web.xml with the following:

<login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/login.jsp</form-login-page>
        <form-error-page>/login.jsp?error=true</form-error-page>
    </form-login-config>
</login-config>

The login.jsp page already exists in the project, in the src/main/webapp directory. This JSP has 3 important elements: 1) a form that submits to "${contextPath}/j_security_check", 2) an input element named "j_username" and 3) an input element named "j_password". If you restart Jetty, you'll now be prompted to login with this JSP instead of the basic authentication dialog.

Force SSL
Another thing you might want to implement to secure your application is forcing SSL for certain URLs. To do this on the same <security-constraint> you already have in web.xml, add the following after </auth-constraint>:

<user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

To configure Jetty to listen on an SSL port, add the following just after </loginServices> in your pom.xml:

<connectors>
    <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
        <forwarded>true</forwarded>
        <port>8080</port>
    </connector>
    <connector implementation="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
        <forwarded>true</forwarded>
        <port>8443</port>
        <maxIdleTime>60000</maxIdleTime>
        <keystore>${project.build.directory}/ssl.keystore</keystore>
        <password>appfuse</password>
        <keyPassword>appfuse</keyPassword>
    </connector>
</connectors>

The keystore must be generated for Jetty to start successfully, so add the keytool-maven-plugin just above the jetty-maven-plugin in pom.xml.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>keytool-maven-plugin</artifactId>
    <version>1.0</version>
    <executions>
        <execution>
            <phase>generate-resources</phase>
            <id>clean</id>
            <goals>
                <goal>clean</goal>
            </goals>
        </execution>
        <execution>
            <phase>generate-resources</phase>
            <id>genkey</id>
            <goals>
                <goal>genkey</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>${project.build.directory}/ssl.keystore</keystore>
        <dname>cn=localhost</dname>
        <keypass>appfuse</keypass>
        <storepass>appfuse</storepass>
        <alias>appfuse</alias>
        <keyalg>RSA</keyalg>
    </configuration>
</plugin>

Now if you restart Jetty, go to http://localhost:8080 and click on the "Users" tab, you'll get a 403. What the heck?! When this first happened to me, it took me a while to figure out. It turns out that Jetty doesn't redirect to HTTPS when using Java EE authentication, so you have to manually type in https://localhost:8443/ (or add a filter to redirect for you). If you deployed this same application on Tomcat (after enabling SSL), it would redirect for you.

Store Users in a Database
Finally, to store your users in a database instead of file, you'll need to change the <loginService> in the Jetty plugin's configuration. Replace the existing <loginService> element with the following:

<loginServices>
    <loginService implementation="org.eclipse.jetty.security.JDBCLoginService">
        <name>Java EE Login</name>
        <config>${basedir}/src/test/resources/jdbc-realm.properties</config>
    </loginService>
</loginServices>

The jdbc-realm.properties file already exists in the project and contains the database settings and table/column names for the user and role information.

jdbcdriver = com.mysql.jdbc.Driver
url = jdbc:mysql://localhost/appfuse
username = root
password =
usertable = app_user
usertablekey = id
usertableuserfield = username
usertablepasswordfield = password
roletable = role
roletablekey = id
roletablerolefield = name
userroletable = user_role
userroletableuserkey = user_id
userroletablerolekey = role_id
cachetime = 300

Of course, you'll need to install MySQL for this to work. After installing it, you should be able to create an "appfuse" database and populate it using the following commands:

mysql -u root -p -e 'create database appfuse'
curl https://gist.github.com/raw/958091/ceecb4a6ae31c31429d5639d0d1e6bfd93e2ea42/create-appfuse.sql > create-appfuse.sql
mysql -u root -p appfuse < create-appfuse.sql

Next you'll need to configure Jetty so it has MySQL's JDBC Driver in its classpath. To do this, add the following dependency just after the <configuration> element (before <executions>) in pom.xml:

<dependencies>
    <!-- MySQL for JDBC Realm -->
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.14</version>
    </dependency>
</dependencies>

Now run the jetty-password.sh file in the root directory of the project to generate a password of your choosing. For example:

$ sh jetty-password.sh javaeelogin
javaeelogin
OBF:1vuj1t2v1wum1u9d1ugo1t331uh21ua51wts1t3b1vur
MD5:53b176e6ce1b5183bc970ef1ebaffd44

The last two lines are obfuscated and MD5 versions of the password. Update the admin user's password to this new value. You can do this with the following SQL statement.

UPDATE app_user SET password='MD5:53b176e6ce1b5183bc970ef1ebaffd44' WHERE username = 'admin';

Now if you restart Jetty, you should be able to login with admin/javaeelogin and view the list of users.

Summary
In this tutorial, you learned how to implement authentication using standard Java EE 6. In addition to the basic XML configuration, there's also some new methods in HttpServletRequest for Java EE 6 and Servlet 3.0:

authenticate(response)
login(user, pass)
logout()

This tutorial doesn't show you how to use them, but I did play with them a bit as part of my UJUG demo when implementing Ajax authentication. I found that login() did work, but it didn't persist the authentication for the users session. I also found that after calling logout(), I still needed to invalidate the session to completely logout the user. There are some additional limitations I found with Java EE authentication, namely:

No error messages for failed logins
No Remember Me
No auto-redirect from HTTP to HTTPS
Container has to be configured
Doesn’t support regular expressions for URLs

Of course, no error messages indicating why login failed is probably a good thing (you don't want to tell users why their credentials failed). However, when you're trying to figure out if your container is configured properly, the lack of container logging can be a pain.

In the next couple weeks, I'll post Part II of this series, where I'll show you how to implement this same set of features using Spring Security. In the meantime, please let me know if you have any questions.

AppFuse 2.1 Released!

2011-04-04T09:38:05-06:00

The AppFuse Team is pleased to announce the release of AppFuse 2.1. This release includes upgrades to all dependencies to bring them up-to-date with their latest releases. Most notable are JPA 2, JSF 2, Tapestry 5 and Spring 3. In addition, we've migrated from XFire to CXF and enabled REST for web services. There's even a new appfuse-ws archetype that leverages Enunciate to generate web service endpoints, documentation and downloadable clients. This release fixes many issues with archetypes, improving startup time and allowing jetty:run to be used for quick turnaround while developing. For more details on specific changes see the release notes.

What is AppFuse?
AppFuse is an open source project and application that uses open source frameworks to help you develop Web applications with Java quickly and efficiently. It was originally developed to eliminate the ramp-up time when building new web applications. At its core, AppFuse is a project skeleton, similar to the one that's created by your IDE when you click through a wizard to create a new web project. If you use JRebel with IntelliJ, you can achieve zero-turnaround in your project and develop features without restarting the server.

Release Details
Archetypes now include all the source for the web modules so using jetty:run and your IDE will work much smoother now. The backend is still embedded in JARs, enabling you to choose with persistence framework (Hibernate, iBATIS or JPA) you'd like to use. If you want to modify the source for that, add the core classes to your project or run "appfuse:full-source".

AppFuse comes in a number of different flavors. It offers "light", "basic" and "modular" and archetypes. Light archetypes use an embedded H2 database and contain a simple CRUD example. Light archetypes allow code generation and full-source features, but do not currently support Stripes or Wicket. Basic archetypes have web services using CXF, authentication from Spring Security and features including signup, login, file upload and CSS theming. Modular archetypes are similar to basic archetypes, except they have multiple modules which allows you to separate your services from your web project.

AppFuse provides archetypes for JSF, Spring MVC, Struts 2 and Tapestry 5. The light archetypes are available for these frameworks, as well as for Spring MVC + FreeMarker, Stripes and Wicket. You can see demos of these archetypes at http://demo.appfuse.org.

For information on creating a new project, please see the QuickStart Guide.

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 mailing list or create an issue in JIRA.

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.

Upgrading to JSF 2

2011-03-07T13:24:53-07:00

Last week, I spent a few hours upgrading AppFuse from JSF 1.2 to JSF 2.0. In reality, I upgraded from MyFaces 1.2.7 to 2.0.4, but all JSF implementations should be the same, right? All in all, it was a pretty easy upgrade with a few minor AppFuse-specific things. My goal in upgrading was to do the bare minimum to get things working and to leave integration of JSF 2 features for a later date.

In addition to upgrading MyFaces, I had to upgrade Tomahawk by changing the dependency's artifactId to tomahawk20. I was also able to remove the following listener from my web.xml:

<listener>
    <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
<listener>

After that, I discovered that MyFaces uses a new URI (/javax.faces.resource/) for serving up some of its resource files. I kindly asked Spring Security to ignore these requests by adding the following to my security.xml file.

<intercept-url pattern="/javax.faces.resource/**" filters="none"/>

Since JSF 2 includes Facelets by default, I tried removing Facelets as a dependency. After doing this, I received the following error:

ERROR [308855416@qtp-120902214-7] ViewHandlerWrapper.fillChain(158) | Error instantiation parent Faces ViewHandler
java.lang.ClassNotFoundException: com.sun.facelets.FaceletViewHandler
        at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:401)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
        at org.ajax4jsf.framework.ViewHandlerWrapper.fillChain(ViewHandlerWrapper.java:144)
        at org.ajax4jsf.framework.ViewHandlerWrapper.calculateRenderKitId(ViewHandlerWrapper.java:68)
        at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:179)
        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:113)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)

Figuring this was caused by the following element in my web.xml ...

<context-param>
    <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
    <param-value>com.sun.facelets.FaceletViewHandler</param-value>
</context-param>

... I removed it and tried again. This time I received a NoClassDefFoundError:

java.lang.NoClassDefFoundError: com/sun/facelets/tag/TagHandler
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:247)
        at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:184)
        at org.apache.myfaces.view.facelets.util.ReflectionUtil.forName(ReflectionUtil.java:67)

Since everything seemed to work with Facelets in the classpath, I decided to save this headache for a later date. I entered two issues in AppFuse's JIRA, one for removing Facelets and one for replacing Ajax4JSF with RichFaces.

The next issue I encountered was redirecting from AppFuse's password hint page. The navigation-rule for this page is as follows:

<navigation-rule>
    <from-view-id>/passwordHint.xhtml</from-view-id>
    <navigation-case>
        <from-outcome>success</from-outcome>
        <to-view-id>/login</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

With JSF 2.0, the rule changes the URL to /login.xhtml when redirecting (where it was left as /login with 1.2) and it was caught by the security setting in my web.xml that prevents users from viewing raw templates.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Protect XHTML Templates</web-resource-name>
        <url-pattern>*.xhtml</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>

To solve this issue, I had to make a couple of changes:

Comment out the security-constraint in web.xml and move it to Spring Security's security.xml file.
```
<intercept-url pattern="/**/*.xhtml" access="ROLE_NOBODY"/>
```
Add a rule to urlrewrite.xml that redirects back to login (since login.xhtml doesn't exist and I'm using extensionless URLs).
```
<rule match-type="regex">
    <from>^/login.xhtml$</from>
    <to type="redirect">%{context-path}/login</to>
</rule>
```

After getting the Password Hint feature passing in the browser, I tried running the integration tests (powered by Canoo WebTest). The Password Hint test kept failing with the following error:

[ERROR] /Users/mraible/dev/appfuse/web/jsf/src/test/resources/web-tests.xml:51: JavaScript error loading
page http://localhost:9876/appfuse-jsf-2.1.0-SNAPSHOT/passwordHint?username=admin: syntax error (http://
localhost:9876/appfuse-jsf-2.1.0-SNAPSHOT/javax.faces.resource/oamSubmit.js.jsf?ln=org.apache.myfaces#122)

Figuring this was caused by my hack to submit the form when the page was loaded, I turned to Pretty Faces, which allows you to call a method directly from a URL. After adding the Pretty Faces dependencies to my pom.xml, I created a src/main/webapp/WEB-INF/pretty-config.xml file with the following XML:

<url-mapping>
    <pattern value="/editProfile"/>
    <view-id value="/userForm.jsf"/>
    <action>#{userForm.edit}</action>
</url-mapping>

<url-mapping>
    <pattern value="/passwordHint/#{username}"/>
    <view-id value="/passwordHint.jsf"/>
    <action>#{passwordHint.execute}</action>
</url-mapping>

This allowed me to remove both editProfile.xhtml and passwordHint.xhtml, both of which simply auto-submitted forms.

At this point, I figured I'd be good to go and ran my integration tests again. The first thing I discovered was that ".jsf" was being tacked onto my pretty URL, most likely by the UrlRewriteFilter. Adding the following to my PasswordHint.java class solved this.

if (username.endsWith(".jsf")) {
    username = username.substring(0, username.indexOf(".jsf"));
}

The next thing was a cryptic error that took me a while to figure out.

DEBUG [1152467051@qtp-144702232-0] PasswordHint.execute(38) | Processing Password Hint...
2011-03-05 05:48:52.471:WARN::/passwordHint/admin
com.ocpsoft.pretty.PrettyException: Exception occurred while processing <:#{passwordHint.execute}> null
        at com.ocpsoft.pretty.faces.beans.ActionExecutor.executeActions(ActionExecutor.java:71)
        at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.processEvent(PrettyPhaseListener.java:214)
        at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.afterPhase(PrettyPhaseListener.java:108)
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:111)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)

Digging into the bowels of MyFaces, I discovered a class was looking for a viewId with an extension and no view-id was being set. Adding the following to the top of my execute() method solved this.

getFacesContext().getViewRoot().setViewId("/passwordHint.xhtml");

After making this change, all AppFuse's integration tests are passing and the upgrade seems complete. The only other issues I encountered were logging-related. The first is an error about Tomahawk that doesn't seem to affect anything.

Mar 5, 2011 6:44:01 AM com.sun.facelets.compiler.TagLibraryConfig loadImplicit
SEVERE: Error Loading Library: jar:file:/Users/mraible/.m2/repository/org/apache/myfaces/tomahawk/tomahawk20/1.1.10/tomahawk20-1.1.10.jar!/META-INF/tomahawk.taglib.xml
java.io.IOException: Error parsing [jar:file:/Users/mraible/.m2/repository/org/apache/myfaces/tomahawk/tomahawk20/1.1.10/tomahawk20-1.1.10.jar!/META-INF/tomahawk.taglib.xml]: 
        at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:410)
        at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:431)
        at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
        at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)

The second is excessive logging from MyFaces. As far as I can tell, this is because MyFaces switched to java.util.logging instead of commons logging. With all the frameworks that AppFuse leverages, I think it has all the logging frameworks in its classpath now. I was hoping to fix this by posting a message to the mailing list, but haven't received a reply yet.

[WARNING] [talledLocalContainer] Mar 5, 2011 6:50:25 AM org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider newInstance
[WARNING] [talledLocalContainer] INFO: Creating instance of org.appfuse.webapp.action.BasePage
[WARNING] [talledLocalContainer] Mar 5, 2011 6:50:25 AM org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider destroyInstance
[WARNING] [talledLocalContainer] INFO: Destroy instance of org.appfuse.webapp.action.BasePage

After successfully upgrading AppFuse, I turned to AppFuse Light, where things were much easier.

Now that AppFuse uses JSF 2, I hope to start leveraging some of its new features. If you're yearning to get started with them today, I invite you to grab the source and start integrating them yourself.