Settling on a stack
I wrote a while back about the project I’m currently working on to build a reference application with Terracotta. At that time, we were still trying to decide on exactly what stack to use. It’s kind of a tricky thing because we were trying to decide on a stack that met several goals:
- Used by a significant portion of our customer base (and to a greater extent the industry)
- Frameworks that can stay out of the way to illustrate how to use Terracotta
- Frameworks we actually find tolerable to use :)
Anyhow, we’ve settled for now on this initial stack:
- Web: Spring MVC
- Conversational web stuff: Spring Webflow
- Page layout: Sitemesh
- Email templates: Freemarker
- Dependency injection: Spring
- Security: Spring Security
- Domain persistence: JPA
- ORM: Hibernate
- Database: MySQL
- Build: Maven
- Unit testing: JUnit
- Web container: Tomcat
This is not to say that this stack is any better or worse than any other stack, of course. In virtually every choice here, there were other alternatives we considered as well that would have worked. But this stack seems to be meeting our goals for the moment. The web framework was definitely the most contentious choice and Geert did most of the analysis (since I’m mostly a web n00b).
It’s interesting to note that we chose a big chunk of technologies similar to the one Grails is built on and thus it would be great to build a Grails version of the app as a follow-on phase for comparison. No promises there but maybe some of the G2One guys would help us out.
Getting the initial project structure in place has been more challenging than it should be due to the alphabet soup of technologies involved. The best starting places I’ve seen are the Maven archetypes provided by AppFuse and WebTide, both of which can give you something to play with quickly.
In the case of AppFuse, they definitely give you a fuller framework and tie together a bunch of technologies. They even provide you a full user login system. However, the user stuff is defined in an AppFuse library and is just pulled in by dependency, not created in the actual project structure. I found that (and the number of additional frameworks included) to be a little daunting in trying to adapt that initial structure into what I wanted. The WebTide archetype is much simpler and for me was a better place to start building out. Ultimately, I ended up starting from scratch and just using a lot of the examples provided from these archetypes and so far that’s been successful. At least I understand what’s there.
So far, it’s definitely been a learning experience for me! At least we’re rolling now…
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
I think your choice of stack will accomplish your goals well. My company’s architects have chosen a similar stack for some ecommerce apps and have been pleased with the experience. We chose to do as much as we could with Raible-compliance in mind, so we modeled much of the design using AppFuse for reference.
Let me know if you get into a jam, we had some hurdles with Maven and Spring Security (acegi) that were unexpected, but doable.
The only thing that concerns me is the JPA and Tomcat combo. If you really prefer Tomcat I would suggest Spring HibernateTemplate vs. JPA Entity manager. But if you want the JPA Entity manager, then switch to JBoss for the built-in EJB3 container. Both ways work fine, but mixing Tomcat and JPA without a built-in EJB3 container seems like a hassle (I haven’t tried it).
I can’t agree with Jay regarding the Spring HibernateTemplate. I view that as “legacy” code, originally intended as a workaround for checked exceptions in Hibernate 2.x and earlier. Since Hibernate 3.x and later all use unchecked exceptions, I see no reason to use Spring code in your data access layer. I think using straight JPA is the way to go, and this will work just dandy in a web container without involving all the extra baggage of EJB.
i view java as “legacy” code, new stuff should be written in ruby, because its newer.
Actually, I just invented a new language a few minutes ago, so we’re going to use that because it’s even newer.
I’m curious why Geert didn’t recommend RIFE (www.rifers.org), especially since he’s the main developer for it. As I understand it, RIFE would cover several of the categories listed in your stack.
I haven’t done much J2EE development, but I keep waiting for a new web project to come my way so I could give RIFE a try.
Geert did prototype with Rife and with Struts 2. Ultimately we decided that Spring MVC was the best mix of the goals I had at the top – used widely, stays out of the way, and relatively easy to use.
As I said, any of these (or numerous others like Wicket, Grails, etc) was a possibility but our first go, this was the choice. I’d love to see people take the app that comes out of this (which will be available on our open source forge) and adapt it with other frameworks or libs.
Hi Jason,
the main reason why I didn’t recommend RIFE for this project was that we don’t want people that look at the source code to be stuck with a technology stack that they need to still learn. Therefore, only the most popular ones were really candidates. I personally would have preferred using RIFE and think we’d be much more productive with it, but for the goals of this project it failed the primary requirement, ie. large adoption.
Hope this helps,
Geert