Develop Reference

"Restful" Java WEB MVC frameworks

The application I am developing will be "responsive" , do async communication and pass a lot of JSON back and forth.
I Need a Java MVC WEB framework that supports
1) Minimum amount of BLOAT and "behind the scenes magic". With any framework, there is always a trade-off between framework functionality vs complexity. But, when the time comes when i face a problem and have to "fight the framework"(and that time always comes), I want it to be a fair fight. Minimizing the sheer size of the framework increases the probability of a fair fight.
2) Native RESTFUL support. I.e. route html verbs and perform content negotiation.
3) Straightforward support for processing JSON. Using an arbitrary json processor of my choice, i.e. jackson or gson e.t.c..
4) Straightforward persistance support, e.g. JPA e.t.c.
5) Some set of template systems, e.g. freemarker, velocity e.t.c.
6) Native authentication/authorization security scheme with support for a "role based" security OR Integrate easily with spring security
All of the above should be integrated in the framework. Not in some third party user contributed module that rots away when a new version of the framework comes along.
I sat down for a day and experimented and found the following candidates
Spring MVC 3
1) To get the proverbial "Hello World" example up and running in Spring MVC 3 i needed the following jars:
org.springframework.beans-3.1.0.RELEASE.jar
org.springframework.expression-3.1.0.RELEASE.jar
org.springframework.asm-3.1.0.RELEASE.jar
org.springframework.context-3.1.0.RELEASE.jar
org.springframework.core-3.1.0.RELEASE.jar
org.springframework.web-3.1.0.RELEASE.jar
org.springframework.web.servlet-3.1.0.RELEASE.jar
And finally some definitions in xml file, "dispatcher-servlet.xml". I don't know if that accounts for BLOAT or too much behind the scenes magic. But it doesn't give me a warm and fuzzy feeling of being somehwat in control
2) Spring 3 supports this and from the examples i saw it does not look too nasty
3) Supported, but from the link in (2) it seems as if processing json is limited to using the jackson library. At least if you want to use the magic annotations for content negotation.
Quote:
"Underneath the covers, Spring MVC delegates to a HttpMessageConverter to perform the serialization. In this case, Spring MVC invokes a MappingJacksonHttpMessageConverter built on the Jackson JSON processor. This implementation is enabled automatically when you use the mvc:annotation-driven configuration element with Jackson present in your classpath."
Bit of a warning signal for me. I would like to have clear programmatic control over what JSON processor i am using. Maybe i am missing something here. This qualifies as unwanted "behind the scenes magic" in my book
4) Yep
5) Yep
6) Yes
Play Framework
1) Version 1.2 weighed 88,5 MB on my disk. Doesn't run in servlet container, so getting the hello world example and running was easy peasy compared to spring, where even finding out which jars i needed was shrouded in secrecy. Obviously a lot of stuff happens behind the scenes in play. I guess all I can hope for is that it does not do more than it has to. And that the arcitecture is sane. But, when i have to fight the framework some day, will I be dead on arrival ? Who knows...
2) Yep and it does so elegantly. Thumbs up.
3) Yes, but it uses gson under the covers. Again, why can i not control this programmatically ? Fortunately, one can pass an arbitrary serializer to gson to override the default. And I think that parameter maps to the second parameter of the play renderJSON() native function. So play passes with half a thumb up.
4) Yep. Has a JPA module
5) Yep. Uses groovy. Fine by me.
6) Should be possible by combining the secure and the deadbolt modules. Don't know how well it stacks up against spring security. I dont see any in-built support for password encryption and the likes. And have no idea how difficult (if even possible) it would be to integrate with spring security. Don't know if i would be comfortable deploying sensitive data and relying on the play! framework for security. Would probably have to build something on top of it.
Restlet
Maybe a peculiar candidate as it's marketed to be used for "restless web services". But for my points (1) -(6) and my type of application where most of the user interaction is async, it seems like a good fit. I can run it on static resources or dynamically generated content and spit out any content type.
1) Restlet 1.1.1 is about 54 MB. Glanced the hello world example. I liked the absence of XML files. And just like play it has its own server(jetty connectors). The hello world example looked very clean and easy.
2) Yes, and the approach is very "programmatic"
3) Yes, but it seems only via a jackson extension module. Given the programmatic nature of this framework, it seems likely that there are other options but i didn't find anything in the documentation or in the user group forums.
4) Describes itself as "persistance agnostic". OK, that's good i guess. But i want to persist and not re-invent the plumbing on my own. Or at the very least i want a little howto showing that it CAN be done with some effort. There is a third party jpa module But it's built on restlet 1.0. Restlet has a spring module though, so maybe i can integrate with spring persistance stuff ...
5) Yes, there is a freemarker extension
6) Has a native scheme for this. At a fist glance, not as "rich" as spring security. Again, maybe I can integrate?
SUMMARY
Spring MVC 3: Supports all of the requirements, maybe with the exception of (1). Only concern I have is that it seems complex and I get a vague unpleasant feeling of not being in control. I really don't want to be "bogged down" by the framework later on as my application grows.
Play: Very pleasant experience. Fun even. If only the security scheme was more advanced, or if I could at least integrate with spring security(and find documentation on how to do it)
Restlet: For some reason this framework resonated with me. The Programmatic approach induces a feeling of control. But if I can't do persistance in some easy-cheasy way then it's a no go. Can't really understand why this is not built in. Doesn't everyone need this?
What say people who have used any of the above frameworks?
Are my observations accurate?
Did I leave out a framework that should be here?
Alternatives?

the comparison between Spring and Play is now highly out of date, since Play 2.0 has been rewritten in Scala and is better in almost every possible way.
Check it out: http://www.playframework.org/

I can only speak for Spring here.
When I was forced to use Spring for a non-REST project last year I cringed. Not only did I have just a few days to pick up the basics, I didn't like all the "magic" it did, nor was I familiar with IoC principles.
But it grew on me. It grew on me pretty fast too. Since then, I've used Spring for all kinds of Web projects, including one that exposes a RESTful API.
The strengths of Spring from my perspective are: a) it's actually pretty lightweight and usually keeps out of your way once you've got things configured, b) TONS of examples and a great community for support, c) doing REST is a cinch, once you get your configuration right, d) an API design that makes the gods weep with joy, and e) IoC is life-changing.
Speaking to your concern with bloat... I've used other Web frameworks for Java, and Spring is the least bloaty of them all IMO. It might LOOK like a lot, but it's really not. Compared to Struts and Seam (both of which I still have nightmares about), Spring is antithetical to bloat. Moreover, the IoC will let you get away without having to write tons of boilerplate, making your app less bloaty as well.
You mention you don't want to get bogged down by the framework as your app grows. This will not happen in Spring, I guarantee you. It is designed to stay out of the way and to keep you from becoming dependent on any one framework. Your code--if designed correctly--could drop Spring in the future for something else with not a whole lot of cursing and head banging. It favors convention over configuration, meaning the common stuff should work out of the box without having to tinker around too much. For those things that are off the wall, it gives you enough rope to hang yourself.
In summation, I would highly consider Spring.

The two I can recommend is RESTlet 2.x, which I use on every project. And RESTEasy which I am considering using on an upcoming project.
What I like about RESTlet is all the routing is in one place. It is very feature rich.
What I don't like about RESTEasy, and I have not looked at it all that deeply, is the Annotations have all the routing strewn across the code base on each method, of what could be many classes. Not having them all in one place, will make maintainability more difficult.
Why I am still considering RESTEasy, is having multiple GET methods per class might cut down on the resource class explosion that can occur in RESTlet.
Both are JAX-RS compliant, if that is important, and either one is a solid investment in time and functionality.
As for templating, use StringTemplate, stay away from things like FreeMarker, they just lead to a world of pain in maintainability.

Should I invest in GraniteDS for Flex + Java development?

I'm new to Flex development, and RIAs in general. I've got a CRUD-style Java + Spring + Hibernate service on top of which I'm writing a Flex UI. Currently I'm using BlazeDS. This is an internal application running on a local network.
It's become apparent to me that the way RIAs work is more similar to a desktop application than a web application in that we load up the entire model and work with it directly on the client (or at least the portion that we're interested in). This doesn't really jive well with BlazeDS because really it only supports remoting and not data management, thus it can become a lot of extra work to make sure that clients are in sync and to avoid reloading the model which can be large (especially since lazy loading is not possible).
So it feels like what I'm left with is a situation where I have to treat my Flex application more like a regular old web application where I do a lot of fine grained loading of data.
LiveCycle is too expensive. The free version of WebOrb for Java really only does remoting.
Enter GraniteDS. As far as I can determine, it's the only free solution out there that has many of the data management features of LiveCycle. I've started to go through its documentation a bit and suddenly feel like it's yet another quagmire of framework that I'll have to learn just to get an application running.
So my question(s) to the StackOverflow audience is:
1) do you recommend GraniteDS,
especially if my current Java stack
is Spring + Hibernate?
2) at what point do you feel like it starts to
pay off? That is, at what level of
application complexity do you feel
that using GraniteDS really starts
to make development that much
better? In what ways?

If you're committed to Spring and don't want to introduce Seam then I don't think that Granite DS will give you much beyond Blaze DS. There is a useful utility that ensures only a single instance of any one entity exists in the client at any one time but it's actually pretty easy to do that with a few instances of Dictionary with weak references and some post-processing applied to the server calls. A lot of the other features are Seam-specific as alluded to here in the docs:
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
Generally, the Tide approach is to minimize the amount of code needed to make things work between the client and the server. Its principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring and EJB 3 are also available but are a little more limited.
I do however think that Granite's approach to data management is a big improvement over Livecycle's because they are indeed quite different. From the Granite docs:
All client/server interactions are done exclusively by method calls on services exposed by the server, and thus respect transaction boundaries and security defined by the remote services.
This is different to how Livecycle DS uses "managed collections" where you invoke fill() to grab large swathes of data and then invoke commit() methods to persist changes en-mass. This treats the backend like a raw data access API and starts to get complicated (or simply fall apart entirely) when you have fine-grained security requirements. Therefore I think Granite's approach is far more workable.

All data management features (serialization of JPA detached entities, client entity caching, data paging...) work with Spring.
GraniteDS does not mandate anything, you only need Seam if you want to use Seam on the server.

Actually, the free version of WebORB for Java does do data management. I've recently posted a comparison between WebORB for Java, LiveCycle DS, BlazeDS and GraniteDS. You can view this comparison chart here: http://bit.ly/d7RVnJ I'd be interested in your comments and feedback as we want this to be the most comprehensive feature comparison on the web.
Cheers,
Kathleen

Have you looked at the spring-blazeDS integration project?

GraniteDS with Seam Framework, Hibernate and MySql is a very nice combination. What I do is create the database, use seamgen to generate hibernate entities then work from there.

What are the advantages of Apache Wicket? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm not a Java developer so I might get some terms wrong... but.
An application I integrate with is moving from Spring to Wicket. While it should not affect my integration with it I got to wondering why they would do this?
From what I know Spring is the more popular framework. I know nothing about it except it's popular. I did read the Wicket page and Wicket seems really simple and straightforward.
What are some of the advantages of Wicket?
It seems to me that changing your entire framework would be some work so I wonder if Wicket offers something that Spring does not?

Advantages that often get touted in circles I frequent are:
Your html can be fully xhtml compliant - there is a VERY nice separation of presentation and logic in that the only thing your presentation/html layer needs to know about wicket are wicketid attributes in standard html tags. This is wonderful for the html/css/javascript client side guy on your team who does little to no actual java work. No other java based web framework can claim this, afaik.
No xml config for anything wicket specific - everything can be done in source and very little needs to be done to the standard web.xml for your .war
component based development is pretty easy to grok - especially if you have a non web background (e.g. a swing programmer). it encourages reuse quite a bit more than mvc does, imo.

Here are some features of apache wicket:
POJO Component Model
Pages and Components in Wicket are real Java objects that support encapsulation, inheritance and events.
Ease of Development
Because Wicket is Java and HTML, you can leverage what you know about Java or your favorite HTML editor to write Wicket applications.
Separation of Concerns
Wicket does not mix markup with Java code and adds no special syntax to your markup files. The worlds of HTML and Java are parallel and associated only by Wicket ids, which are attributes in HTML and Component properties in Java. Since Wicket HTML is just HTML and Wicket Java is just Java, coders and designers can work independently to a large degree and without relying on any special tools.
Secure
Wicket is secure by default. URLs do not expose sensitive information and all component paths are session-relative. Explicit steps must be taken to share information between sessions. Furthermore URL encryption allows highly secure web sites.
Transparent, Scalable Clustering Support
All Wicket applications will work on a cluster automatically and without additional work. Once bottlenecks are understood, Wicket enables tuning of page state replication. The next version of Wicket will support client-side models for zero-state scalability.
Transparent Back Button Support
Wicket supports configurable page version management. When users submit a form or follow a link from a page they accessed with the back button in their browser, Wicket is able to revert the page object to the state it was in when the page was originally rendered. This means you can write web applications that support the back button with very little work.
Multi-tab and multi-window support
Wicket provides an easy way to write application that supports multi-window and multi-tab usage allowing developer to react properly when users open new browser window or tab
Reusable Components
Reusable components in Wicket are particularly easy to create. Not only can you extend existing components with the Java extends keyword, but you can also create Panel components which associate a group of components as a reusable unit.
Simple, Flexible, Localizable Form Validation
It is trivial to write and use validators in Wicket. It is also quite easy to customize and localize the display and content of validation error messages.
Typesafe Sessions
Wicket eliminates the need to manage HttpSession attributes by hand. Page and component objects are transparently stored in the session and your application can create a custom session subclass with typesafe properties as well. All objects stored in the session can automatically participate in clustering replication.
Factory Customizable
Wicket is very extensible. Most operations are customizable through factories or factory methods.
Detachable Models
Model objects in Wicket can be very lightweight in terms of memory and network use in a cluster. When a model is used, it can “attach”, populating itself with information from persistent storage. When the model is no longer in use, transient information can be reset, reducing the size of the object.
Border Components
Wicket Border components enable the decoration of pages in a reusable fashion. This is especially useful for inheritance of common navigational structures or layout.
Support for All Basic HTML Features
Wicket supports image tags, links, forms and everything else that you’re used to using in your web application development.
Programmatic Manipulation of Attributes
Wicket Components can programmatically change any HTML tag attribute.
Automatic Conversions
Once a Form validates, the model can be updated using Wicket converters. Most ordinary conversions are built-in and it is easy to write new converters.
Dynamic Images
Wicket makes image use, sharing and generation very easy. Dynamic images can be created by simply implementing a paint method.
Pageable ListView
ListViews in Wicket are extremely powerful. You can nest any kind of component in a ListView row, even other ListViews. PageableListView supports navigation links for the large lists.
Tree Component
Out of the box tree component for navigating and selecting nodes.
Localization
HTML pages, images and resource strings can all be localized.

Spring's more than Spring MVC. You can (and probably should) use Spring with Wicket.

Wicket rocks!
Spring (which has a UI module called Spring MVC) just seems to be a mega, 'do everything, including the kitchen sink', type of framework which made it appear huge and unwieldy to me when I started to evaluate Spring (and Spring MVC). Today Spring doesn't seem to me to be focussed on any one thing. Originally I think it was simply a dependency injection framework but it quickly grew to try to be all things to all people and the simplicity was lost.
The books I read on Spring had examples that contained way too much XML config. Errors in XML config files are a lot harder to debug and fix than errors in java code which you can single step through with your debugger.
What's wrong with declaring stuff in Java code instead of XML anyway? Since when did someone decree that everything should be declared in XML anyway? If you like swimming in a sea of complex XML config files then go with Spring. If you like getting work done and being productive then go with Wicket.
Wicket is very focussed on being the best Java based UI framework for web app development. It doesn't try to lock you into any particular dependency injection framework or any particular persistence framework (use it with JDO/JPA, DataNucleus, Hibernate, whatever).
It's focus is clearly on UI but you can use any dependency injection framework you like (you don't have to use Spring's DI with it but you can if you want). We even use our own DI (http://www.expojo.com) with Wicket and all is funky.
Update
I was recently working on a Spring project and had to come up to speed with it and everything I had suspected about Spring in my initial evaluation was true but there were many more surprises that made it much, much worse than I had imagined.
With annotations littered through the code the start up time of Spring based app compared to the same app before being "Spring enabled" was well more than tripled.
Debugging by single stepping through "your" code is a nightmare whenever you traverse a line of code that has been "AOPed" by Spring's AOP which seems to reach its tentacles into virtually every class. What looks like it should be a single step into a line of your code leads to a hyperjump into a 37 level deep labyrinth of AOPed, Spring framework code.
This happens for almost everything - not the least any ORM (eg. Hibernate/JPA, DataNucleus/JPA) related methods. If you're wondering why apps run slower with Spring/Hibernate compared to non AOPed calls to an ORM like DataNucleus then those 37 deep "implicit" AOPed calls should give you some hint...
Oh and the potential for "gotchas" is next level. Try using 'synchronized' on an Spring transactional annotation and see how 'synchronized' it actually is! Scary!
I understand Spring's popularity (although appears to be waning lately): because a lot of people don't think - they just blindly use tech because they assume it's great because other people are using it. That was never a good assumption - remember EJBs??? (Worse tech ever but every job ad back in the day required EJB "skills")

Spring is more all-encompassing than Wicket.
Wicket is a Java web UI framework. Spring has one as well, along with modules for persistence, remoting, security, messaging, etc.
Spring is built on dependency injection and AOP. Wicket has neither.
I have not used it, but it's supposed to be simple. I can't say whether Spring is easier or harder.
You can use Spring to good advantage in a lot of situations besides web applications.

You can read about the advantages of using Wicket in the free first chapter of Wicket In Action: http://www.manning.com/dashorst/
In short, Wicket is a great framework when the application you're developing is relatively complex, you want it to be maintainable, being able to scale the team and take advantage of reuse. Object oriented programming proved to be a very useful paradigm for programming UIs, but unfortunately, most Java frameworks for developing web applications, including Spring MVC, only support a very procedural programming model where they tag the term MVC on to make it sound cool (but in fact, since the granularity they support are request/ response roundtrips rather than self contained widgets, MVC is really misleading).
The DI part of Spring is great, and is something you can easily use together with Wicket.

I agree with the answers provided so far. What hasn't been mentioned are the following points, which are a consequence of Wicket's approach of web application development focussed on Java code:-
Wicket development does not involve writing JSPs.
AJAX components can be developed without involving the writing of Javascript.
I haven't come across any other framework which takes this Java-centric approach. All the others I've used (Struts, Spring) involve JSP development.
For me a big advantage of Wicket is the focus on Java, and availablity of rich development environment tools like Eclipse. Also the very clean separation of business logic from presentation aspects of the application.

Some advantages of Wicket I like:
Simplicity - Learning curve is small especially if you are from Swing school.
Clean Separation of Concerns - Web designer does not need to know much about the codes.
Ease of Deployment.
Here is my blog to show hello world codes in Wicket

Spring gives you the MVC design pattern only at the page level -- a very coarse level of granularity indeed. Wicket, in contrast, gives you the MVC design pattern at the individual component level (much as Swing offers for fat client programming). With Spring MVC, all of a form's data is global to the entire front servlet, so there is not much opportunity for information hiding, loose coupling, or tight cohesion. With Wicket, your display logic can be much more modular -- the data managed by componentA need not be visible to the code for componentB.
The smaller level of granularity makes it much easier to reuse display code across a number of different web pages or even across web applications.
Also, because component configuration is done in Java rather than XML, they can be configured on-the-fly at run-time, making for much greater power and flexibility (as contrasted with most other component-oriented frameworks such as ASP.NET Web Forms or Java Server Faces).

One other advantage of Wicket over other popular java web frameworks is that it allows you to create modular and extensible web applications. This is particularly useful when you are designing a web based product, which you intend to extend by adding extra functionality and pages in the form of plugins at deploy time, and eliminating the impact on the core functionality/source of your product. Here is a very good article on it.
http://www.infoq.com/articles/modular-wicket

Is there any other strongly-integrated presentation layer tool other than JSF/JSP for Java EE?

I'm teaching Java EE at the university, and this was a question a student asked. I said "no", but I wasn't really sure, so I thought I might ask you mighty developers. :)
Basically, what I'd like to do is to use entities if they were in my context: cat getters, setters, etc, so like normal POJOs. if I use an EJB using its remote inferface, the entities gets decoupled from the core infrastructure, so that's a no-go.
I thought about writing a layer such as this in my MSc thesis. If it's a dead idea, feel free to tell me. If it's not, tell me if you'd like one.
Or if there is such a tool out there, let me know!

In a basic modern world Java EE application, it is broken into various layers, where you have 4 basic layers
+--------------------+
| Presentation |
+--------------------+
| Controller/Actions |
+--------------------+
| Business Delegate |
| (Service) |
+--------------------+
| Data Access Layer |
+--------------------+
| Database |
+--------------------+
Your applications should be split into these layer right from the beginning, such that you can at any given point of time replace any layer without effecting any of it's sibling layer.
Example if you used JDBC for the Data Access layer, you should be able to replace it with Hibernate without affecting the business delegate or Database layer. The benefit of using such an architecture is to allow collaboration with multiple technologies. You business delegate (service layer) should be able to talk to a web service and handle the application processing without even going to a browser!
Regarding using JSP as the presentation layer, there are other technologies available like, velocity, freemarker, as iberck mentioned above, tapestry also has it's own rendering engine. You can use XML + XSLT also to render the UI. There are UI managing apps also available like Tiles and sitemesh, that help you integrate various techs as different components of the page and show them as one.
You can also use light weight swing components clubbed with JNLP and develop a desktop style enterprise application. All we need is a little imagination and client requirement and we can use literally anything as the presentation layer.

I've never tried it, but JSF is supposed to work better with Facelets than with JSP.
IBM has an article about it.

Ah. It seems you didnt get my question right :)
Beans are there to provide services inside an application. Lets say I'd like to develop a standalone java application with a swing gui, and from that application I'd like to use the entities present at the java ee app's scope.
That is what I'd like to to seamlessly: create entities, modify them, delete them in an intuitive way, without caring about EntityManager-detachment problems (if you call an EJB remotely and it passes back an entity object, it will be detached before return).
I dont want to develop a web application. JSF/JSP and such is strongly integrated, but in many environments a standalone client application would be better. :)

Seeing your comment in the middle, i see that you want a desktop framework over Java EE.
The answer here is that JSF works over the servlet api. And is definitely for the web, but wait, you can still embed tomcat or jetty in your application!
The possibilities are pretty much endless, if your business layer is well defined, just build a swing layer that calls your business functions.
Also, Java EE is an API, some parts can be replaced, or you can just use part of it. The container is mostly for dealing with EJB, Servlets JNDI and other small stuff. All this can be used by desktop apps also.
So the answer depends on your specific goal and the actual design/implementation of the application.

One alternative is the Spring Framework. Spring provides its own support for binding entity objects to the view and handles the getting/setting for you once it is wired up. There are many Spring modules to pick and choose from. Spring MVC and Spring Webflow are both worth checking out. Spring MVC (IMO) is simpler to get started with, but Sring Webflow allows for more complex navigation and more scope options (ex: flow scope). If you're looking for a book Spring In Action is descent. There are some concepts you will need to tackle (such as dependency injection) in order to use Spring but it is well worth the time.

Another alternative is Tapestry5 framework.
Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server.
Tapestry divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting. Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java code. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects -- and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications.

The ideology behind beans is nowadays in any proper Java framework I know of. As rich mentioned, Spring is a good/great all-around business logic framework (check out its jdbc template classes, those are simply awesome - another great gem is applicationContext.xml which is ) and for view layer I personally prefer Apache Wicket.
I don't believe you should make your own but instead find a framework that suits your needs and start contributing to its code base, that way you get to start with an already formed user base and your code will get authored more thoroughly which in turn will make you a better programmer.

grails (http://www.grails.org/) or griffon (http://griffon.codehaus.org/) may be of interest

StringTemplate is written by Terrence Parr, the guy behind ANTLR. If you're interested in generating some kind of textual presentation from a model, this is very good.
I have had excellent results using it to generate XML, web pages and dot files from the same model. You write a template to render an object. That template can call other templates (including recursively), based on the data derived from the model. (q.v. Picture Functions)
Getters and map.get() are callable directly from within the templates. The model can be any POJO. ST prides itself on its strict separation from the controller, so very little logic is allowed in the templates themselves.
As with all these little languages, it's something new to learn, and may not be what you're looking for. It was a really good fit for me.

Practical Experience using Stripes?

I am coming from an Enterprise Java background which involves a fairly heavyweight software stack, and have recently discovered the
Stripes framework; my initial impression is that this seems to do a good job of minimising the unpleasant parts of building a web application in Java.
Has anyone used Stripes for a project that has gone live? And can you share your experiences from the project? Also, did you consider any other technologies and (if so) why did you chose Stripes?

We've been using Stripes for about 4 years now. Our stack is Stripes/EJB3/JPA.
Many use Stripes plus Stripernate as a single, full stack solution. We don't because we want our business logic within the EJB tier, so we simply rely on JPA Entities as combined Model and DTO.
Stripes does the binding to our Entities/DTO and we shove them back in to the EJB tier for work. For most of our CRUD stuff this is very thing and straightforward, making our 80% use case trivial to work with. Yet we have the flexibility to do whatever we want for the edge cases that always come up with complicate applications.
We have a very large base Action Bean which encapsulates the bulk of our CRUD operations that makes call backs in to the individual subclasses specific to the entities and forms.
We also have a large internal tag file library to manage our pages, security, navigation, tasks, etc. A simple CRUD edit form is little more than a list of field names, and we get all of the chrome and menus and access controls "for free".
The beauty of this is that we get to keep the HTTP request based metaphor that we like and we get to choose the individual parts of the system rather than use one fat stack. The Stripes layer is lean and mean, and never gets in our way.
We have a bunch of Ajax integrating YUI and JQuery, all working against our Stripes and EJB stack painlessly.
I also ported a lighter version of the stack to GAE for a sample project, basically having to do minor work to our EJB tier. So, the entire stack is very nimble and amicable to change. Stripes is a big factor of that since we let it do the few things that it does, and does very well. Then delegate the rest to other parts of the stack.
As always there are parts folks would rather have different at times, but Stripes would be the last part to go in our stack, frankly. It could be better at supporting the full HTTP verb set, but I'd rather fix Stripes to do that better than switch over to something else.

We use stripes now on all our production sites, and have been for about a year now. It is an awesome product compared to struts, which we used to use before that. Just the fact that there are literally no XML config files and that you can set it all up with a minimal amount of classes and annotations is awesome.
In terms of scaling & speed it actually seems to be better than struts, and my guess would be because there are less layers involved. The code you end up with is a lot cleaner as well, because you don't have to go off to seperate XML files to find out where redirects are going.
We use it with an EJB3 backend, and the two seem to work really well together, because you can use your EJB POJO inside your actionBean object, without needing a form object like in struts.
In our evaluation we considered an alpha version of struts (that supported annotations) and a lot of other frameworks, but stripes won because of it's superior documentation, stability and clean-ness.
Couldn't figure out how to leave a comment: so to answer your second question we haven't encountered a single bug in Stripes that I know of. This is quite impressive for an open source framework. I haven't tried the latest version (1.5) yet, but 1.4.x is very stable.

We converted a home-grown web framework to stripes in about a week. We're using it in production at this time and it's a great framework. The community is extremely helpful, and the framework doesn't get in your way. It can be extended in many places to change the behavior as you see fit. The url binding feature is awesome as well. We implemented a robust security framework using annotations and interceptors. We're using spring for dependency injection and stripes has excellent support for that.
I'd definitely use the new 1.5 release if you're going to use it.
I'm a huge fan of the framework. I came from a struts background and it's the exact framework I was looking for. The other developers on our team really enjoy using the stripes framework.
I just bought the stripes beta book from the pragmatic programmer's site. It's a great resource on Stripes 1.5.

We have now used Stripes in multiple production projects and so far the experience has been great. Setup time is low and the configuration management issues seem to be fewer. We have webapps running with Stripes/Dojo/Hibernate and others with a mix of Stripes/Spring/JSP/Jquery etc. Adding Stripes to our existing projects was fairly simple thanks to their support for integrating existing Spring configurations. Using Stripes with JSP is fun although sometimes you do feel the need to code in Java and not have to use the JSTL so much.
Note:
This is an old question, but given that it pops up pretty fast when you search for Stripes usage, I am adding a response to it.

I also came from a Struts and JSF background into Stripes. I went from a large enterprise environment that used mostly struts and JSF on newer projects, to a smaller environment that did all their J2EE in Stripes.
Seems like Stripes gives you what you want in a Web Framework without getting in the way too much. Not much configuration is necessary, as others have already mentioned. Very quick development and allows you to focus on presentation etc. instead of hassling with the framework.
If I had to start a fresh new project and I had my say, I would choose either Stripes or JSF. I might have been scared away from Stripes if I had to make the decision to switch to it, because it kind of looks/feels like a sourceforge basement project instead of a enterprise-grade framework, but it seems to be fairly solid. We use Stripernate for easy ORM.
However, it reminds me of Fruit Stripe gum, which lost its flavor WAY TOO FAST.

Stripes is yesterdays technology, if you can pick something a little more modern like GWT.