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?