Matt RaibleMatt Raible is a writer with a passion for software. Connect with him on LinkedIn.

The Angular Mini-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.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
You searched this site for "mvc". 279 entries found.

You can also try this same search on Google.

[OSCON] Spring MVC vs. WebWork Smackdown

Matthew Porter and I's Spring MVC vs. WebWork Smackdown presentation was a lot of fun this morning. We had a boxing bell (that I got off eBay) and had a good time ragging on the two frameworks. The only surprise was that Matthew actually ran some metrics on the Spring MVC vs. WebWork code in AppFuse and pointed out that the WebWork version required 25% less code than the Spring version. Oh well. The hard part about this presentation for me was trying to defend Spring MVC and saying it's better than WebWork. Matthew obviously felt strongly that WebWork was the better framework, whereas I like them both.

Posted in Java at Aug 03 2005, 05:15:43 PM MDT 7 Comments

[DJUG] Building an Open Source ESB and Ruby on Rails

Managing Chaos
Building an Open Source Enterprise Service Bus from Scratch

Bruce Tate got rained out in Texas, so Bruce Snyder and Jeff Genender are talking about building an ESB with open source software. Bruce and Jeff created this product in the last project they were on. I was lucky enough to work with them on it the first half of this year - but only after the ESB was created. The final product was very stable and the client loved it.

Bruce is a Geronimo committer and one of the founders of the Castor project. Jeff is also a Geronimo guy and is currently working on a JBoss Live book for SourceBeat. The problem that the ESB was trying to solve was fixing a horrendous data flow. A lot of the data flow was occurring between people's PCs, shared drives, FTP servers, HTTP Servers, web servers - and rarely were things automated. Bruce recalls one of his first days when he heard the trading guys yelling at each other to "close the spreadsheet".

The solution to the problem was building an Enterprise Service Bus (ESB) that performed the following:

  • Centralized Management of Activities
  • Powerful Scheduler
  • Guaranteed Event and Activity Execution
  • Durable Transactions
  • Pluggable ESB Components for Activities
  • Staging Database for Single Common Data Location
  • Logging and Notification of Activities
  • Proactive Response to Failed Activities
  • J2EE Architecture - Provides for True 24/7 Uptime

The pluggable components were called transformers and were standalone JARs that lived on their own, but could be managed by the ESB. Notifications were key so the traders would be notified when something went wrong.

Architecture

Scheduler (Quartz) » Workflow (jBPM) » Persisted Guaranteed Messaging (JMS). JMS talked to Activities (a.k.a. transformers).

The Quartz Java Scheduler is an open source project from OpenSymphony. It's a persisted scheduling engine, so it'll live through app server restarts. It also has millisecond granularity.

For workflow, the Java Business Process Manager (jBPM) was used. It doesn't use BPEL, and was used to track multiple activities and make decisions based on an activity's completion or failure status. Other functionality included tracking the activity state (running, cancelled, completed) and sending/managing notifications. Workflow was very important because the previous system had no way of detecting where things failed in a process. With the new system, downstream dependencies were handled, the escalation path was based on success or failure - and automatic retry occurred on failures if the failure reason was a known and configured expectation.

For messaging, JMS was used - implemented with EJB and MDB. This provided guaranteed and persisted messages. Events were automatically recovered if the server failed.

Activities/Transformers were pluggable components (wrapped with EJBs for transactionality). The nice thing about using EJBs was it was easy to create JARs for each transformer, drop them into JBoss and they'd immediately become available.

The system was all managed with a management console, that was a webapp implemented in Struts, Spring and Hibernate. Most of the Spring and Hibernate classes and configuration was generated with Middlegen and XDoclet. The management console allowed you to kick off activities, monitor their progress, as well as manage users with Active Directory and single sign-on with NTLM and jCIFS.

Solution Facts

Since December 2004, over 200,000 jobs have been run through this system. Of those, 500K activities have been run, with < 10,000 failed activities (2% failure rate). Nearly all failures were due to external issues, such as unavailability of remote systems and databases, or source files not available.

Tools and APIs Used

When Jeff showed up, it was a Microsoft shop using ASP, Visual Studio and some PowerBuilder. They brought Jeff in to help them use and adopt open source. The first thing they did was install and begin to use CVS (previously source control was done on shared drives). They also used Maven to build everything and produce a project site - which the managers and C-types loved. One thing they mentioned is they often got questions from higher-ups like "How much does it cost?" They did have problems with Maven, but it was mainly due to the poor documentation. They found a lot of Maven solutions by cracking open plugins and looking at their Jelly files.

Development Lessons Learned

Configuring EJBs and MDBs as singletons helped solve some problems (a JBoss setting allows you to configure this). As for running Spring in a heavily-managed environment, they found that setting singleton="false" solved a lot of problems. The next problem they had was mixing Hibernate and JTA Transactions. No details, just that they had an interesting time and it took them a few days to get it working. The last problem they encountered was using Hibernate and/or Spring JDBC to manage hundreds of thousands of records. Since these O/R tools create objects for each record, OOM errors occurred with large resultsets.

Business Lessons Learned

All notification messages came from the ESB, leading many to believe the problem was the ESB - rather than the data sources it was talking to. By using open source, they saved the company $500K in licenses fees. The interesting part was the company had a 3rd-generation agreement with IBM, and owned $12 million worth of licenses for WebSphere and WSAD. The reason this group used open source was because there weren't enough licenses.

Bruce and Jeff's presentation was good, but they looked like a couple of goofballs standing up there in their t-shirts and shorts (standard Virtuas gear). I guess that's what happens when you get a 2-hour notice. The worst part about the presentation was the fact that the A/C doesn't work and it's about 85° in here. I told Geary he'd better keep in short or I'm outta here. ;-)

Ruby on Rails
David Geary

David got into Rails by reading an article called "Rolling with Rails". In the article, the author claimed that you can develop webapps in Rails at least 10 times faster than in Java. David responded to the article on his blog with an entry called the Ruby on Rails Koolaid. He experienced quite a butt-whooping from various folks, including Rails' founder - and realized afterwards that the claims might be valid. After working with Rails, David believes that Rails is probably 5-10 times faster.

Ruby

Potent mix of SmallTalk, Perl and Python. Everything is an object. No static type checking. Duck Typing (talks like a duck, walks like a duck, it probably is a duck). Testing usually solves the lack of static types. Blocks - like anonymous inner classes, but retain state. Mixins - a cheap way of doing multiple inheritance. Dynamic classes - can modify at runtime (add methods, renaming methods, etc.). Rails takes great advantage of the dynamic attributes as part of its framework.

David is now showing a ContactsController that has 5 methods for CRUDing a Contact object. 4 of the 5 methods are one-liners. It kinda reminds me of my Hibernate DAOs after integrating Spring. ;-)

Rails

Ruby-based MVC framework. Convention over configuration. Scaffolding - builds pieces of your application for you. ActiveRecord does O/R Mapping. Has a built-in testing framework. Near-zero configuration (no XML). Zero-second deploy time (development environment).

David's first demo is being done by audience member Kirk. David asked for a volunteer from the audience with MySQL experience, and the ability to type in a few commands. David said his 6-year old daughter was able to do this demo last night successfully - so Kirk's gonna look pretty bad if he can't pull it off. ;-)

Using scaffolding, Rails generates 1 controller, a test for it, a helper class, a css file and 5 rhtml templates. Kirk pulled off the demo, even though he had a bit of trouble with the Mac environment. This is a lot like AppFuse's AppGen in a sense - except AppGen has to parse a bunch of XML files and reconfigure them.

David keeps hammering that the most productive feature of Rails is that there is zero deploy time. Save. Refresh. It looks very similar to developing a static HTML site.

Rails has ActiveRecord, ActionPack (MVC), ActionMailer, ActionWebService, Ajax Support, Transactions and Security. Currently at version 0.13.1 - the last version before 1.0.

David is delivering an excellent presentation, but it's too damn hot without A/C - I'm outta here.

Posted in Java at Jul 13 2005, 11:03:46 PM MDT 6 Comments

Scaling with Rails

Whenever I talk to developers in the Java community about Rails, the first question out of their mouth is usually "But can it scale?" Today, David has written a nice post titled It's boring to scale with Ruby on Rails.

The one thing that I see time and time again is that Java developers don't seem to realize that some of the highest traffic sites on the net are using LAMP stacks similar to what Rails advocates. IMHO, I don't think "Rails can't scale" is a valid argument. In fact, I don't know if there's any argument or way to put down Rails anymore.

As a developer, my guess is the rates for programming in Ruby developer are less than for programming in Java (unless you're a Ruby Superstar of course), so that's one reason not to program in it. However, since Rails is one of those new bright and shiny things, chances are you might be able to get high rates for it. As far as Enterprise Adoption of Rails, unfortunately I think that's still pretty far on the horizon. I think the hardest part is convincing management that they'll be able to find developers to support it. Mind you, I didn't say good developers, just developers. Period. This is information I've gathered from talking to my Java developer friends.

Try convincing a Fortune 500 company to program in Rails vs. Struts and they'll probably choose Struts because there are thousands of Struts Developers. Is this a good decision on their part? I don't think so. I think it's more important to hire smart people that can learn a technology, rather than hiring those that know a technology. Of course, if someone knows a technology really well, there's probably no harm in hiring them.

I think Rails can become a real contender in the Enterprise if managers can be convinced that it'll be easy to maintain Rails application. Remember that most of software cost is maintenance. Because of this, the whole "it's super productive to develop with" doesn't matter so much - does it? Are Rails applications easy to maintain? My guess is yes, but how do you convince CTOs and CIOs? Another thing I think Rails needs for Enterprise Adoption is good tool support. Drag and Drop type of stuff. Why? Because management loves that stuff (because then they can develop apps) and it's a great sales tool. ASP.NET has been successful because of Visual Studio, not because of its ease-of-use and simple syntax.

Will I learn Rails and use it to develop applications? I certainly hope to, but it's hard enough convincing companies to use something other than Struts - so I don't know if I'll have much luck in selling Rails. The one cool thing about my new job at Virtuas is its an open source company, not just a Java open source company. This opens the doors for me to learn about Rails (and others) and compare them to Java Web Frameworks.

Update: Aaron Rustad has written an interesting article for DeveloperWorks that compares Rails to Struts+Hibernate: Ruby on Rails and J2EE: Is there room for both?

Posted in Java at Jul 12 2005, 08:45:26 AM MDT 28 Comments

AppFuse 2.0: JDK 5, Annotations and JSP 2.0

For the most part, I haven't used JDK 5 on any of my recent projects. You can compile and run AppFuse with JDK 5, but it doesn't use any JDK 5 features. After doing a code review at Bouvet last week and seeing how much cleaner their code is with Generics, Varargs and the Enhanced for Loop, I think it's time to dig in. I don't know how soon we'll start, but I think it's time to start creating a branch for AppFuse 2.0 - which will use these features. For AppFuse 2.0, I'd like to go whole hog, bleeding-edge and use all the stuff that's out there to make developer's lives easier. This includes JSP 2.0, Annotations (especially for Hibernate and Spring, as well as Tapestry) and all the JDK 5 features that seem useful.

Since most developers won't be able to deploy on a JDK 5-compliant server for quite some time, we'll continue to maintain the 1.x branch as JDK 1.4-compliant. I expect to release AppFuse 1.8.1 later this week (with mostly bug fixes + latest releases of Hibernate/Spring) and 1.9 in the next month or so. From there, we'll likely do 1.9.x releases with bug fixes and do all the major upgrades (i.e. Tapestry 4.0.x) in the new branch. Working with new features in JDK 5 should be a lot of fun.

I'm hopeful that we can get rid of XDoclet and we may even give Maven 2 a run for its money. Last week in Norway, I found that most Java developers were using Maven on their projects and I also discovered that many of the core Maven 2 developers are getting paid to work on it full time. There were even claims that Maven 2 is going to be twice as fast as Ant - which definitely intrigues me.

Later: I just realized the hardest part of this migration is going to be replacing AppGen. It currenly uses XDoclet templates for all the class templates - and we'll need a new solution based on annotations. Oh well, it's kind of ugly anyway, but it'll likely be difficult to figure out a new solution. Hopefully we can create some sort of tool that involves easy-to-customize templates and a GUI to drive it all.

Posted in Java at May 30 2005, 12:41:52 PM MDT 27 Comments

My Next Big Adventure

I mentioned last week that my next professional endeavor was going to provide more time to work on AppFuse and Spring Live. Now I guess I should explain what my next big adventure is. ;-)

As most of your know, I've been writing Spring Live for SourceBeat. When I signed up with them in March of last year, their grand vision for the company wasn't just to write books - it was to become a training and consulting provider as well. They wanted us as authors to eventually write training that we could deliver on-site, as well as at our facilities in Denver. As far as consulting, they wanted to provide consulting in the true sense of consulting - where we give advice and help people implement open-source in their environments. Not the code-monkey kind of consulting/contracting, but rather the big dollar kind of consulting.

Now they've got an outlet for that venture.

Not only have they gotten funding for developing training programs and providing open-source mentoring to CIOs and CTOs, they've got the connections to make it work. Furthermore, we think we've established a team that will make this a tremendous success. Many of us have been independent consultants for quite some time - so we all have a certain desire to make things happen for ourselves without having any loyalty to a particular company, or person in charge. We've all decided to give up our independent status to build a company together - because we think this venture can actually provide more freedom than independent consulting provides.

If we do it right, we plan on doing training and consulting for a week or two per month, and then working on driving the open source movement the rest of the time. All of us expect to dedicate more time to the books we're authoring, as well as contribute more to open source projects. We also plan on writing more articles and trying to help out the community more - to promote open-source tools and make them easier to use through good documentation.

At this point, you might be wondering who "We" is. As of this point in time, Matt Filios is heading up the show. He's the current CEO of SourceBeat, and it's his ideas that've made SourceBeat a unique and fun publisher to work for. Starting this new company has been in his "idea bank" for quite some time, so it's great to see his enthusiasm and energy in getting this thing off the ground. He has a lot of connections and excellent business sense to make this new company a sure success. It's great to have someone in charge that you trust and feel confident about.

Having a business leader makes good sense for a company, but you also need a technology leader. For that, Bill Dudney has stepped up to the plate and will try to keep us focused and make sure we're not goofing off all the time. Bill's role is as Vice President per se.

From there, we're establishing a number of "Practice Leaders" that are experts in a particular area, and can provide training and high-level consulting for particular technologies. I will focus on my core expertise as the Spring and Web Frameworks Practice Leader. We have also added Bruce Snyder and Jeff Genender with their in-depth knowledge and expertise in application servers and databases, and will continue to add Practice Leaders in a host of areas, including operating systems (Linux of course), databases, and other applications.

The new company's name is Virtuas, and our headquarters will be in downtown Denver. Our new office is only a few blocks from my last contract, so I'm pretty pumped that I can continue to ride my bike to work. The best part about this new job is it's not really a job. It's starting a company, pursuing a passion, and doing the stuff I normally do at night and on weekends. I won't need to switch gears anymore when I go to "work", but rather just learn, promote and teach the technologies I'm passionate about. How cool is that?! :-D

Posted in Java at May 26 2005, 08:15:57 AM MDT 28 Comments

Java Jobs: broken down by web framework

I updated my Web Framework Comparison presentation today. Rather than updating the graph that shows today's job availability, I did one that compares today to 6 months ago. Struts is still the clear winner (and growing). Spring is definitely growing. Tapestry has about the same amount of jobs (9 vs. 8). WebWork lost 10 opening (down to 4) and the demand for JSF skills has grown as well.

Is WebWork a dying framework? I've heard folks complain about its small community, and there still aren't any books is only one book about it. Is that a jab at Patrick, Jason and Kris - or a jab at Manning? I'm not sure. ;-) The good news is WebWork in Action and WebWork Live should both be out this summer.

Web Framework Jobs

My search criteria for all of these was "framework and java" from the front page on dice.com. I did filter a bunch out for WebWork b/c there's some product called "WebWorks" that folks want to hire for.

In my own experience, these numbers are not as accurate as you might think. Since I gave my original presentation, I've been contacted a number of times to work on projects. It's about even between Struts, Spring MVC, WebWork and JSF. I haven't had a single inquiry to do Tapestry development. The bad part about Struts jobs is there's so many of them, that rates are likely pretty low (i.e. 35-45/hour), whereas the others can get you upwards of 80-90/hour.

So what do these numbers mean? Do they mean you should tailor your learnings and skills to the most popular frameworks? In a sense, it's important to do so. If nothing else, Struts skills are import so you can migrate all the Struts applications to your favorite framework. However, I don't think these numbers are that important when choosing a framework to start your project with. I think the most important thing in choosing a framework is passion. Which one do you want to work with the most? It's likely that your productivity will be higher if you're enthusiastic about the framework, rather than bored with all the skills you've accumulated using it. Then again, if you're motivated by productivity more than enthusiasm - using your skills to crank out applications quickly is probably a good idea.

You might think that the number of skilled developers for framework X is important too. I don't think it is. I think the most important thing is to hire smart developers. A good developer can come up to speed on any framework in 2 weeks and be highly productive in 4 weeks. If not, the developer isn't that smart or the framework isn't that good. ;-)

Just for kicks, I did some searching for other web frameworks as well:

  • Rife: 0
  • Wicket: 0
  • Echo: 3
  • Ruby on Rails: 1
  • ASP .NET: 2876

Now the question is - what kind of rates are these skills getting? I'd like to know what the average Rails and ASP .NET developers make. In Denver, Java developers seem to make between 65-85/hour when they're experienced contractors.

Posted in Java at May 22 2005, 07:28:01 AM MDT 13 Comments

Spring Training in Norway

A week from today, I'm heading to Norway to do some training on Spring. It's going to be a good trip and I have my work cut out for me. I'll be talking about Spring, Hibernate, AppFuse, Acegi Security as well as Ajax and Spring Web Flow. I'll also be presenting at the two JUGs in Norway:

  • Stavanger JUG, May 25th: Test-Driven Developing with Spring and Hibernate. I also plan on talking about Spring Web Flow for a good portion of this meeting.
  • Oslo JUG, May 26th: Advanced Spring MVC, Spring Web Flow and Acegi Security.

I'll try to post outlines for my presentations in the next week or so.

Posted in Java at May 13 2005, 10:48:47 AM MDT Add a Comment

[OSCON] AppFuse Tutorial and Spring MVC vs. WebWork

AppFuse Home Now that the OSCON 2005 site is up, I might as well advertise the two things I'm doing: an AppFuse Tutorial and a session titled WebWork vs. Spring MVC Smackdown with Matthew Porter. I wasn't planning on doing the AppFuse Tutorial, but I was asked to do it - so what the heck. The title has "Struts" in it, but I'm willing to do whichever one (JSF, Struts, Spring MVC, Tapestry or WebWork) the audience chooses. If we're good, maybe we'll have an Eclipse Plugin done by this conference to simplify the new project and code generation process.

OSCON 2005

Posted in Java at May 07 2005, 08:45:40 PM MDT 2 Comments

AppFuse Videos

I know I said I'd never do an AppFuse video, but after having many requests - I decided to go ahead and make a couple. The first one is a demo of creating a new project and then installing and browsing that project in your browser - to see all the out-of-the-box features.

The 2nd one basically all the stuff that's done in the tutorials - using Spring MVC for the web framework. I create a Person.java object and then use AppGen to generate all the code for it. In this one, I make a number of mistakes (but solve them all). I thought about going fully happy-path, but then decided it was important to show some gotchas that might occur.

I used the trial version of Camtasia Studio to create these videos. Thanks to Keith at KGB Internet for hosting the demo site for AppFuse. If you need Tomcat hosting, Keith offers an excellent service at a very good price.

Update: You can also download these videos for off-line use.

Update 2: I updated these videos for AppFuse 1.9.3.

Posted in Java at May 04 2005, 09:48:40 AM MDT 32 Comments

Using DWR with Spring and Hibernate

For the past few weeks, I've been developing an application using Struts, Spring, Hibernate and the DWR project for my XmlHttpRequest framework. As you might remember, I used JSON-RPC for Ajax stuff on my last project. I found DWR to be much more full-featured and easier to use. This post is meant to capture some issues I encountered so others won't have to jump the hurdles that I did. For those of you that get bored quickly, here's a movie (QuickTime) of the app's Ajax features.

I've been using version 0.4 of DWR, and I haven't had a chance to try out version 0.5. When I first started using it, I ran into a ThreadDeath problem that was easily resolved by changing a log.debug message to System.out.println. I tried to reproduce this issue yesterday and couldn't, so who knows what that was all about. As far as configuring DWR in your webapp, that's pretty easy to do, and well documented. See the project's documentation or this Spring MVC HowTo.

Here are a few things I remember from my development experience.

  • The examples are great, especially how to dynamically edit a table.
  • When developing, make sure to set the "debug" init-param to "true". This allows you to go to http://location:8080/yourapp/dwr and see a screen that allows you to call methods on your exposed classes.
  • In WEB-INF/dwr.xml, you need to specify a converter for each POJO you want to expose to your UI via JavaScript. I started out by converting a whole package, but found this to be *extremely* slow (we have a package of around 50 DTOs). So I changed it to be only the DTOs I was using. This turned out to take about 30 seconds to do the conversion, and was again unacceptable. The problem turned out to be that the converter was invoking all the lazy-loaded children for each DTO. My final solution was to create a NameValue object and only convert that. Then in my Spring bean, I populate it from DAOs and DTOs. I'm using Spring's OSIVF for Hibernate to ensure that DWR doesn't invoke lazy-loading.
  • I had to override a few of DWR's JavaScript functions in util.js b/c they didn't work for me. I changed showById() and toggleDisplay() to use style.display='' instead of style.display='block' b/c this is what I've always used and block doesn't work that well. I also changed useLoadingMessage() to have a cleaner-looking load message.
  • I used the Fade Anything Technique in this project and found that IE likes to have full 6-digit hex values for colors in CSS rules. The shorter 3-digit hex values simply don't work in IE.
  • Using "test" buttons that only showed up for my username proved to be a great way to test the UI and the Ajax stuff. These buttons called a number of JavaScript functions to drive the UI and wait between invoking different functions using window.setTimeout.

All in all, using DWR was a great experience and I definitely plan to use it more in my projects. The client loves the app - especially since it's wicked fast and seems to work like a desktop app.

Posted in Java at Apr 28 2005, 02:10:26 PM MDT 31 Comments