Which Java Web Framework fits best with Google Guice?

Question

I'm planning to start on a new project and am looking at the current state-of-the-art Java web frameworks. I decided to build my application around Guice, and am likely to use a very lightweight ORM like Squill/JEQUEL/JaQu or similar, but I can't decide on the web framework. Which one would fit best in such a lightweight environment? And which one integrates best with Guice?

Answer 1

A good lightweight web container is Simple. Its extremely performant and can be used with frameworks such as Restlet and Jersey.

Answer 2

Wicket has a guice module built in, which I haven't used (but I have used wicket quite a bit, and liked it).

http://herebebeasties.com/2007-06-20/wicket-gets-guicy/

Answer 3

please excuse if there are annoying typos in this post. i have not proofreaded it yet. please drop a comment if you spot some errors (grammatical or otherwise)

i have gathered some experience on this topic, as i started to program on a new project in november, the project is in a late stage now.

for me, the following design guidelines were important:

• use a modern techology stack that is both fun to use and will be in general use in future.
• reduce the number of project artifacts - use annotations/java code where it makes sense, omit xml.
• use frameworks that are open-source
• have an active community
• are not alpha stage
• are lightweight
• avoid duplication of concepts
• i can explain the concepts in it to my 2 fellow developers, who - despite being good programmers - have never used DI or web frameworks.
• can serve as a techological basis for future projects

guice as a DI container was an obvious choice - clearly the most well-thought DI contianer, brilliant developers, good community, and it fulfills all the bullet points mentioned above.

so what i did, i set up my basic techology stack. started with guice, added hibernate for persistance (along with warp-persist and warp-servlet). then i wrote some basic Dao that selects something.

then i tried to do the following: add a different web framework on top of that.

• xslt with xStream using regular httpservlets
• jsf- myfaces
• apache wicket
• warp-widgets

i created a simple page with a table,populated by the dao, headers and a textfield with all 4 frameworks.

these were my findings when comparing the four frameworks.

xslt+xstream is kind of a hardcore-approach. its not really a framework, but a viable completely stateless techology for high-performance apps. this was by far the fastest way of serving the test page. in debug mode 3 ms on localhost versus about 30-50ms with the other framworks. guice integration was relatively smooth and good using warp-servlet which enabled me to inject into servlets and injects httprequest, httpresponse, session in other objects, without passing them around. disadvantages: no community at all, since i am the only person who would consider this stack. - no ready-to-use components.

then i took a look at jsf+guice: it is of course possible to put the injector in the servlet context and use guice as a service locator. with the straightforwars approach its impossible to inject backing beans somewhere else. using a custom variable resolver solves this partially, but then you lose all ide integration in your jsf files plus you will have to use ugly FQN for your backing beans, or build a string->guice key mapping somewhere. both are ugly as advantages: good community, many developers in the job market (no criteria for me). you won't get fired for chosing jsf if something goes wrong. disadvantages: brings its own IoC mechanism which clashes conceptually with guice.

warp-widgets: i created my simplte example using this for fun, its early alpha stage. it was nice to use and its components are easy to implement and reuse by myself. it aims to provide typesave html with perfect guice integration. since it looked like it had only one active developer back then, who is now propably working on guice 2.0 i would say the community is nearly non-existent. worked like a charm, was reasonably fast, but i would have been alpha tester, that was simply too risky for me to consider it for a commercial project.

apache wicket: this project first suprised me with wicket-ioc and wicket-guice coming together in the core download. constructor injection in web pages is not possible, only setter+field. injection in wicket web pages is easy, just add @Inject tp the fields you want to fill - but you're not supposed to understand how it works in background. tricky stuff happening. injection of web pages is theoretically possible - but i have not used it once, since this makes it impossible to use mounted urls, plus it will mess with the persisted/serialized state. injected members of classes are dealt transparently with web page serialisation, which is necessary for enabling browser-back support. wicket uses zero external artifacts - just a little config of the urls in a application class. so all configuration is done in java - which fits the guice model well. clear seperation of html+java.its open-source just like the majority of the components that are numerous and of good quality. its around since 2005 ? and is a top-level apache project. although its a feature-rich framework its api is reasonable compact (all core classes fit in a single jpg on my screen). unlike others, it brings no own IoC mechanism of its own, but rather thinks of IoC as a service that can be provided by spring, guice, etc. and that philosophy makes it superior w.r.t. guice integration. did i mention really smart+easy ajax support?

frameworks not deeply evaluated: tapestry5 - brings its own IoC. seam: not a framework on its own, but a meta-framwwork which normally comines spring, jsf. hibernate. (though spring may theoretically be replaced by guice)

summary: of the evaluated framworks, apache wicket was the clear winner - with respect to guice integration + all other criteria mentioned.

besides us two, some other people have had this problem before.

Answer 4

Here's an article on integrating Guice with Stripes