Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

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.

Jetty vs. Tomcat vs. Resin: A Performance Comparison

This morning, I did some comparisons between Jetty 5.1.5rc1, Tomcat 5.5.9 and Resin 3.0.14 (OS version). I ran AppFuse's "test-canoo" target, which tests all the JSPs using Canoo WebTest. I did this as a Servlet 2.4 application, and had to tweak some stuff in my web.xml to make it work on Jetty and Resin. Nothing big, just stuff that Tomcat let pass through and these servers didn't. One interesting thing to note that Resin requires you to use "http://java.sun.com/jstl/fmt" for JSTL's "fmt" tag URI, while Jetty and Tomcat require "http://java.sun.com/jstl/fmt_rt". This is with Resin's "fast-jstl" turned off - b/c everything blows up if it's turned on (I don't feel like coding my JSTL to Resin's standards, that's why I turn it off).

Below is a list of the average time it took to run "test-canoo" after I ran it once to compile all the JSPs.

  • Jetty: 19 seconds
  • Tomcat: 19 seconds
  • Resin: 29 seconds

In addition, I tested how long it took for each server to startup - including the initialization of AppFuse.

  • Jetty: 7 seconds
  • Tomcat: 8 seconds
  • Resin: 13 seconds

So what does all this mean? A number of things:

  • I need to clean up AppFuse's web.xml a bit for 2.4 applications.
  • Putting the database connection pool configuration in a Spring context file (vs. JNDI) makes AppFuse much more portable.
  • Jetty isn't as fast as Jetty-lovers say it is (or maybe Tomcat just caught up).
  • The open source version of Resin is much slower than the other open source servlet containers.
  • I should restructure the build.xml to pull out Tomcat stuff and allow users to specify server deployment settings (i.e. in a ${servername}.xml file).
  • Orion still doesn't support the Servlet 2.4 or JSP 2.0 specifications.

Posted in Java at Sep 15 2005, 10:52:50 AM MDT 12 Comments

Should I change AppFuse's default web framework?

Currently, the default web framework in AppFuse is Struts. It's nothing fancy like Shale or Struts Ti, but rather Struts Classic. Even though Struts is not dead it's a pain in the ass to work with compared to other MVC frameworks like Spring MVC and WebWork. Yesterday, on the AppFuse Mailing List, I kicked off an informal poll about switching to a different default web framework. I think most of the people that choose Struts w/ AppFuse are choosing it b/c it's the default. Making another framework the default would likely same quite a few users a lot of headaches.

So which one should I make the default? Here's my thoughts from the mailing list thread:

I like Spring MVC and WebWork better than Struts, but I believe that WebWork is much easier to understand and develop with. Unfortunately, it's not well documented or marketed, so it's a bit difficult when you run into snags. Of course, if you contact the user community via forums or e-mail, answers flow quickly.
...
I'd like to use the framework that's simplest to understand. Right now, in my eyes, that's WebWork. I think JSF and Tapestry are excellent too (as component-based frameworks), but Tapestry's learning curve is difficult and JSF has a lot of issues (like everything is a post). Hopefully things will get better with JSF 1.2, but it's probably another 6 months before MyFaces supports 1.2 - let alone the app servers.
...
Maybe we should just drop Struts altogether - or replace it with Struts Ti? Unfortunately, it'll probably be a while before it's ready for production (I doubt it's that useable now).

Of course, if a WebWork Book was out - this move would be a lot easier. I did talk to Patrick Lightbody on IM yesterday and he said "it's done" and supposedly he has copies, but I haven't seen anything on the WebWork Blog to prove this.

A related question: how much would it hurt AppFuse if I dropped Struts altogether and went with something like Wicket instead? I'd like to keep that cap at 5 web frameworks. If I dropped Struts and added Wicket, I might lose potential users, which might not be a bad thing. ;-)

Posted in Java at Sep 15 2005, 07:32:51 AM MDT 32 Comments