VRaptor 3 offers deep integration with dependency-injection frameworks; with Spring and PicoContainer support ready out of the box. In fact, VRaptor runs inside the DI container, enabling full integration: you can use all Spring components along with VRaptor. An API is also available to support other DI frameworks. We also integrate with Hibernate, so that your components can simply have the session injected and VRaptor takes care of the rest. A pleasant outcome of the focus on testability and IoC is that the framework is easy to extend, for instance users can add Converters or change the name conventions. VRaptor intends to make it easy to write RESTful applications. You can have readable URIs and effortlessly bind path parameters to method arguments. It's also trivial to bind certain controller methods to HTTP verbs. In another portion of our effort to make web development more pleasant, we made sure to be refactor-friendly: users never have to refer to other methods or classes through Strings. We invite you to check out our 1-minute tutorial: http://vraptor.caelum.com.br/documentation/vraptor3-one-minute-guide.

How can you compare this with Seam?

I've read the ten minutes tutorial and it really reminds me the Click framework. However a thing is strange: you make the same mistake as Click people, i.e. public fields in classes. Why? Please don't do it! Every time God sees a public field kills a kitten.

I've read the ten minutes tutorial and it really reminds me the Click framework.
However a thing is strange: you make the same mistake as Click people, i.e. public fields in classes.
Why? Please don't do it! Every time God sees a public field kills a kitten.

I like Click very much, and I must correct that: you are not required to use public fields. I don't use them. Making them private requires a manual add to the page. You can choose what you use.

I've read the ten minutes tutorial and it really reminds me the Click framework.
However a thing is strange: you make the same mistake as Click people, i.e. public fields in classes.
Why? Please don't do it! Every time God sees a public field kills a kitten.

I like Click very much, and I must correct that: you are not required to use public fields. I don't use them. Making them private requires a manual add to the page. You can choose what you use.

What I would like to see, in Click and in VRaptor, is to map properties, not fields, automatically as public fields are mapped. Is it possible in VRaptor?

Actually vraptor does not work with public fields at all as exposing public fields is not considered a good practice. It also does not require the use of class inheritance as Click's first example shows (but maybe its optional when using click). Yes, it is! If you register the CustomProvider for vraptor2 compatibility mode, there is native support for properties. But I would not recommend them because one controller is responsible, usually, for more than one action within one resource, which would make you create a few properties which are only useful for one method, others for other methods... if not taken care properly, this will lead to property-hell. But thats just an advice... you can still do it! Regards

Hi Antonio, that was an error on the tutorial. We're terribly sorry! Thanks a lot for noticing it. As Guilherme answered, VRaptor doesn't need (nor recommend) using public fields - they should all be private on the ten minutes tutorial. The docs are being re-generated at this very moment and it will be corrected asap.

Hi Antonio, that was an error on the tutorial. We're terribly sorry! Thanks a lot for noticing it.

I feel better now, so do the kittens :-D