Matt RaibleMatt Raible is a Web Developer and Java Champion. 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.


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.

Resin slower than Tomcat, fails the AppFuse Test

As part of AppFuse 1.6, I was hoping to supply the option to use Resin instead of Tomcat. In reality, hardly anyone has asked for this on the mailing list - but since so many folks say that "Resin is better" - I figured I'd give it a whirl. I hate to be the guy that spoils all the Resin users mantra, but it seems like Tomcat is the better server. Why? Speed, compliance and shit works. Here are some things I found:

  • Server startup time when AppFuse is only app installed (deleted work directories before starting):
    • Resin: 25 seconds
    • Tomcat: 14 seconds
    I also found that Resin loads my StartupListener twice b/c it's defined in web.xml and XDoclet puts it in the generated TLD. I think the best solution is to add a flag to XDoclet to allow you to exclude listeners from the TLD when it's generated. I commented out the entry in web.xml for this test.
  • Running "ant test-canoo" which runs through all the JSPs using Canoo's WebTest (server already started):
    • Resin: 1st run (no compiled JSPs) - 53 seconds, 2nd run (compiled JSPs) - 24 seconds.
    • Tomcat: 1st run (no compiled JSPs) - 49 seconds, 2nd run (compiled JSPs) - 14 seconds.

I did have to hack a number of things to even run the tests (which verifies titles, success messages, etc.) on Resin. First of all, SiteMesh seems to puke with if you try to use <dispatcher>FORWARD</dispatcher> on the filter-mapping. I had to comment this out, resulting in a lots of HTML Tidy errors during the tests ( Error: <content> is not recognized!). I also had to turn off Resin's fast-jstl to bypass this bug. Finally, I had to revert the displaytag to using the non-EL version (which required changing titleKey -> title and name="${listName}" -> name="listName"). It seems that Resin enables EL even if you're using a 2.3 DTD. With Tomcat, and I believe the spec says this, EL is only enabled if you use a 2.4 XSD.

So there you have it folks, not only is Resin 3.0.9 slower than Tomcat 5.0.28 (JDK 1.4.2, Windows XP), but it's not standards compliant. Of course, the speed could be due to my using the open source version (with performance enhancements turned off) - but I'd think the other (albeit minor) stuff should be easy to fix. Everytime I try to use Resin, I end up finding bugs and going back to Tomcat. I guess this is another one of those days. I don't think I'll include a Resin installer as part of 1.6, but I might distribute one later if I can get these issues solved. I wonder if I should give Orion a run for its money?

P.S. Since I know people are going to ask: Tomcat 5.5.3 with JDK 5.0 took 9 seconds to startup. Running "test-canoo"? First run: 37 seconds, second: 14 seconds. Looks like the new compiler is quite a bit faster.

Posted in Java at Oct 07 2004, 07:13:09 PM MDT 24 Comments

I use Resin 2.x. Less libs (4) and super quick. Then again, I don't use any of that fancy "JSP two dot oh"

Posted by Patrick Lightbody on October 07, 2004 at 09:23 PM MDT #

Actually, AppFuse is a Servlet 2.3 and JSP 2.1 app - so it should run on Resin 2.1. To be fair, I tested AppFuse on Resin 2.1.14. The only bug I found was with the ClickstreamListener, which I commented out. Test results:

<ul class="glassList">
  • Startup time: 11 seconds
  • 1st run (no compiled JSPs): 42 seconds, 2nd run: 26 seconds
  • The startup time is indeed impressive, as well as the first run time. However, it's disappointing to see that the 2nd run is slower than the other two. I do like Resin 2.1.x better than 3.0.x - I only needed to disable the ClickstreamListener and turn of fast-jstl in resin-web.xml to get it to work.

    Posted by Matt Raible on October 07, 2004 at 09:57 PM MDT #

    Matt, I use resin all the time, and occasionally fire up my apps and test them in tomcat. Everything always works in resin, then I have to change things to get them to work in tomcat. My point is that things are always going to work in the app server that you primarily use first and there will be idiosynchrosies in other apps servers. As for the performance stuff, I have a email into resin support to get more clairification on that, but I think that it is refering to some things like caching that you would have to explicitly use/turn on either in the code or in the config file, but I'll let you know once I hear back from them.

    Posted by Paul Barry on October 08, 2004 at 06:26 AM MDT #

    Resin is slow when it has to complile the JSPs or other resources, but after that it is generally very fast. I would be curious to know where the real slowness was. While your test is a nice anecdote, I would rather judge based on actual production experience. I have been a Resin user in production for a while, and have been very happy with the stability and the speed. If there are other problems, the support if phenomenal. I think Tomcat is great, too, and the choice of app servers is one of the strong points of Java. I would argue that Resin (and Tomcat) are really viable options. To me, the debate is less about Resin versus Tomcat, and more about these simpler containers (which are cheap if not free), versus the clumsy huge containers that I find myself wrestling with in frustration.

    Posted by Ben Tomasini on October 08, 2004 at 09:12 AM MDT #

    Paul, see my comment to Matt's earlier blog post on "Resin now Open Source?".

    Matt, I think it would be great if you would post your feedback/bug reports to Caucho. As I mentioned before, they're very responsive. While they may not be able to do anything about performance in the open source version, they should at least fix the bugs you've found. Nothing gets better unless somebody tells the person(s) who can do something about it. It still amazes me that Microsoft (and others, too, I admit) has trained everyone so well to not bother to send feedback because they don't listen. Give it a try and see what happens. Also, you can still download and test the professional version. It's always been available for personal non-commercial use and many people end up buying it anyway. I think it would be worth seeing what kind of times you get with that one.

    Posted by gerryg on October 08, 2004 at 10:15 AM MDT #

    What about jetty?

    Posted by peter morelli on October 08, 2004 at 11:29 AM MDT #

    I'd like to try Jetty, but I spent 10 minutes trying to figure out how to configure a JNDI DataSource and JDBCRealm for user authentication and came up empty handed.

    Posted by Matt Raible on October 08, 2004 at 02:25 PM MDT #

    I like resin since I can develop live without reploying. It reloads classes nicely unlike Tomcat. I will still be telling my clients that Resin is faster under load, it's priced very reasonable. I sugest that you should allways test any application on at least 2 diferent containers!

    ps: How do I turn of email of thread comments?

    Posted by Vic on October 08, 2004 at 05:17 PM MDT #

    Currently, there is no feature in Roller to "turn off" e-mailing of comments. If you enter your e-mail address - you're automatically signed up for other comment responses. However, since I have full control over my Roller database - let me know which thread(s) you'd like to unsubscribe from and I'll delete your e-mail address in your comment(s)

    Posted by Matt Raible on October 08, 2004 at 07:24 PM MDT #

    Tomcat also reloads classes nicely, at least versions 5.x and 5.5.x. No need to redeploy an application.

    Posted by Lars Fischer on October 08, 2004 at 10:33 PM MDT #

    Posted by Anothermike on October 09, 2004 at 11:22 AM MDT #

    After I'd posted those links I actually understood that you meant a JDBCRealm which gets its connections from a JNDI DataSource. To do that, you need to extend the JDBCUserRealm to go get the JNDI DataSource. AFAIK there is no implementation for that in the base Jetty package. Could be wrong.

    Posted by Anothermike on October 09, 2004 at 11:31 AM MDT #

    hey Lars how do you get tomcat to reload your modified classes without having to redeploy the whole webapp?

    Posted by francisco hernandez on October 11, 2004 at 06:00 PM MDT #

    The context of your application must be defined as reloadable. If you have your webapp in "exploded" format and your IDE (I use IDEA) compiles classes to WEB-INF/classes, just put a file <youfilename>.xml in $CATALINA_HOME/conf/Catalina/localhost. The file should look like this:
    <?xml version='1.0' encoding='utf-8'?>
    <Context docBase="/<directory path for the exploded webapp>" path="/<name>" reloadable="true"
    Now if you compile a class in your IDE, Tomcat reloads your context automatically. This applies to all files, not just Java classes.

    Posted by Lars Fischer on October 12, 2004 at 01:58 AM MDT #

    Look at, I'm just to dumb to display xml in html code :-)

    Posted by Lars Fischer on October 12, 2004 at 02:17 AM MDT #

    Interesting tests -- thanks for carrying them out and posting your results. For Tomcat 5.5, we're still fairly new to Jasper-JDT integration. We expect to get even better JSP compilation performance as we become more familiar with the compiler's switches and behavior. I always develop on Tomcat, because its standards compliance is the best. I usually also deploy on Tomcat because for scenario I've had (only dozens of projects and years of production deployments, but who knows maybe my sample size is small/lucky ;)) its performance is every bit as good if not better than all other servers, including Resin and Jetty. When I don't deploy on Tomcat standalone it's due to other requirements, such as the customer already having a Weblogic farm. But in the past couple of years, even those customers have been switching gradually and under the radar. Anyways, I'm going off-topic -- thanks again for testing Matt.

    Posted by Yoav Shapira on October 14, 2004 at 07:07 AM MDT #

    Jetty user here. Noticed the comments that JDBCRealm isn't available in Jetty - I think it's a relatively new addition, but according to the following Javadoc, it is available now, at least since 5.1.2: org.mortbay.http.JDBCUserRealm API Doc

    Posted by Steve Sobol on July 27, 2005 at 08:35 PM MDT #


    Posted by on December 27, 2005 at 05:02 AM MST #

    Matt, I also use Tomcat to power my site (actually Tomcat sits behind Apache web server). But for development, especially with Struts development, I find it easier to do on Resin, since it gives better error messages. In most cases where Tomcat fails to pinpoint the JSP line that causes the problem, Resin does a good job. Once everything works, then I move to Tomcat for production.

    Posted by Kevin Le on February 23, 2006 at 06:23 PM MST #

    Uh oh.

    We use Resin to run our production app.servers cluster.

    1) we switched from resin's clustering to our jgroups
    2) we try to make our jsp's standards-compliant but we end up making them only resin-compliant
    3) we try to make our servlets, filters and listeners standards compliant, but resin caches filter chain, tries to persist session to DB on every value put into it, uses its buggy sax/xslt implementation, inserts arbitrary symbols in jsps so we catch them with <c:set />, doesn't follow JavaBeans convention on boolean getters (isXXX()), etc.
    4) does something really nasty preventing our app from being redeployed (holds ClassLoader or ???)
    5) changes its stupid hessian every 5th minor release
    6) deserializes classes with no constructors (hessian 3.0.20 stopped this stupidity)
    7) running it with its supa-dupa-fast native sockets slows down
    8) its 200 threads kill performance with context switching

    good server.

    We'll use Jetty in next major release

    Posted by Elijah Epifanov on January 31, 2007 at 08:55 PM MST #

    I have been using resin for production for 3 years. From my experience resin is always faster than tomcat. During development I sometimes run the webapp in tomcat to see if the jsp files are standard compliant.

    Posted by sura on February 10, 2007 at 12:59 AM MST #

    I'm not sure how you use either Tomcat 5/6 or Resin 2/3 to reload modified classes (IDEA). Tried againsts jdk 1.4, 1.5, 1.6. Both servers, reload=true, etc. Anyone can pass me a resin.xml file and server details so that I can find out what's different? Thanks.

    Posted by florin on May 02, 2007 at 01:11 AM MDT #

    Anybody reading this as a app server comparison, please realize this is by no means a performance comparison. Unless I'm completely missing something, there is only a single thread doing the request(s), while in a live environment there will be lots of concurrent request. App servers usually perform quite different under different loads.
    So DO NOT use this comparison to base a decision between Tomcat and Resin for deployment.
    (Also, there is a more recent, though still single threaded, comparison here:

    florin, use -Xdebug when starting Resin to get HotSwap (see

    Posted by Mattias Jiderhamn on October 18, 2007 at 02:01 AM MDT #

    @florin: For resin2 to reload modified classes: Structure your project the way as expected in a war file, e.g. let IDEA compile to <BaseDir>WEB-INF/classes. Add an web-app element to your resin.conf: <web-app id='myApp' app-dir='<BaseDir>'> </web-app> if you can't use WEB-INF/classes or WEB-INF/lib, use the classpath-element.

    Posted by on May 26, 2008 at 09:25 AM MDT #

    Post a Comment:
    • HTML Syntax: Allowed