Is it possible to use facelets as view technology with Spring MVC? There is no mention about it in the official documentation, but I've heard that Facelets are very convenient and easy to use and I'd like to try it, I just don't know how...
It might be worth trying Spring Web Flow, that comes with JSF2 (facelets) support:
http://static.springsource.org/spring-webflow/docs/2.3.x/reference/htmlsingle/spring-webflow-reference.html#whatsnew-swf-220
This link to the official documentation has a sample app integrating Spring WebFlow with faces.
It is possible to configure Spring MVC with Facelets. Check the solution here: https://github.com/acichon89/springmvcfacelets
Yes, You can. Rather very well you can have JSF frontend, Spring framework in the middle and probably Hibernate/webservice/JDBC in the backend.
For actions initiating from the JSF page which you migh expect to call the Spring in the backend, the controller in the JSF should call the Spring POJO and then onwards the it's all Spring to take care, you may have to pass on your bean from JSF to Spring bean.
Sometime back I found this document, hope it helps you.
Related
I want to build a server for my android application.
My application lets users register and allows each user to request a list of all users registered to my application, so my server will be mainly in charge of receiving data from a user, updating the database, and sending data back to user on request.
Since I've never built a server I looked into what would be the ideal way to achieve my goals and after some reading I've found that Spring would be the right way to go, But I also found that there are all kinds of springs.
Eventually I've narrowed my options down to Spring MVC and spring Boot,
I've read that spring boot is a good start but I also read that spring boot does all the configurations for you and I want to really know how stuff works so I fear that spring boot will do all the work for me , So I thought of maybe using spring MVC but I couldn't completely figure out if Spring MVC would be good to achieve my goals or if it's mainly used for building web pages
So what would be the best suitable spring to use ?
I would prefer Spring boot. It's not just about it doing all the configuration for you. It's about Spring saving you from writing a lot of boilerplate code (you still have to do a fair bit of configuration though). Plus, it will be easy to spin up the app and test it locally (you can even test it with local file based h2 database, meaning you don't need to install any database into your machine).
Adding Spring Data JPA dependency with Spring boot will take care of persistent layer as well. And if you want to write jsp or html pages then I would recommend having a look at this thymeleaf example.
Here's the sample CRUD application I have developed with Spring boot and here's my own blog about it.
Spring MVC stands for model,view,controller. View, in general is something which is returned after your business logic has been executed and mainly suggests webpages. Spring Boot would be the easiest way to set up your server for the application. However, if you want to know how things work you can go with the basic spring. Spring, too provided classes like JdbcTemplate to reduce your boilerplate code, however it forces you to configure things yourself.
You do not have the comfort of annotating a resource and watching as the magic happens. If you want to speed up setting up a server and make things less complex go for Spring Boot.
We are planning to make a new application with spring 4.0.6 version. We use controller that can return "XML" or "JSON".
In the previous project we have successfully implemented Jersey with Spring for REST support using JAX-RS API, but after reading a few articles and suggestions from seniors they said spring is providing pretty good REST support.
Some of the points that really confused me if I use Spring REST support without using JAX-RS and Jersey are:
How marshaling and unmarshaling done in Spring MVC ?
Is it necessary for marshaling or unmarshaling need to use jax-rs.
If marshaling and unmarshaling are automatically handled by spring then how does it know about xmlRootElements.
I am still confused if Spring proving very good support of REST then why do people still go with Jersey for REST?
Really looking to know more in details.
If I said anything wrong please ignore it.
Explanation with example is really helpful.
I'd say both Jersey and Spring MVC are great - each project has its own style and strengths. Anyway, Stack Overflow is not the right place for asking subjective comparisons (your question would be closed quite quickly). If you're already using Spring for everything else and are not required to use JAX-RS, then Spring MVC makes total sense.
Regarding features like (un)marshalling, JAX-RS is just a spec after all - other libraries can offer similar features without implementing the same API.
Instead of MessageBodyReaders/Writers, Spring MVC is using HttpMessageConverters to handle (un)marshalling REST resources. Spring MVC handles content negotiation and chooses the best available converter for the job (you can annotate methods to hint at what media type they produce/consume).
No, it's not necessary to use JAX-RS to (un)marshall resources. In fact, JAX-RS implementations and Spring MVC use third party serialization libraries to do the job; so it's not tied to a particular standard.
In its 4.0.6 version, Spring supports many HttpMessageConverters, with Jackson for JSON, JAXB for XML and many others. Spring 4.1.0 added more HttpMessageConverters:
Jackson is now available for both JSON and XML
Google Protobuf
Gson for JSON, as an alternative to Jackson
To answer your last point, #XmlRootElement is a JAXB annotation and is not part of JAX-RS. Spring supports JAXB.
For a more complete example with REST in Spring, check out this getting started guide (you'll get a complete example running in 10-15 minutes).
Again the last part of your question is quite subjective - there are many popular solutions for building REST services in the JVM, not just Jersey and Spring (Dropwizard, Play! Framework, etc).
AFAIK Spring REST support is based on Spring MVC and its not JAX-RS implementation while Jersey has implemented JAX-RS specification.
Those having Spring (Core, AOP or MVC) in their project chooses Spring ReST support over JAX-RS implementor.
I recommend Jersey as its mature, implements JAX-RS and is easy to use.
In one of our projects we are using the spring mvc. The spring mvc has inherent support for REST web services. I am looking forward to some insight/suggestions on how does Springs mvc's REST support fare when compared with the other popular framework like RESTEasy, RESTlet,JAX-RS etc.
The first big differentiator is that Restlet and RESTEasy both provide implementations of JAX-RS. You can write JAX-RS code that either of those frameworks could run and not have to change anything. Spring MVC is a separate API that doesn't implement JAX-RS. It does provide most of the same functionality from what I've seen. Of course, Restlet also provides its own non-JAX-RS based API which is nice too.
I found this seemingly thorough comparison of Spring MVC and JAX-RS at InfoQ that might interest you. I would say, if you are already using Spring MVC and it meets your needs in the REST department, stick with it until you find a need to look for something else.
What can I use for data access, timers etc? Seam, jBoss, GlassFish? Or simply Tomcat + JSF + Hibernate/JPA?
I need add just one JSF component to Spring MVC pages but I am afraid I must rewrite whole web app to jsf and drop Spring.
jbo, If you are just interested in replacing your view layer, you need not switch to hibernate/jpa etc.. JSF can co-exist with spring MVC. Need not discard any of you business objects and DAO's.
Better option is to consider spring-webflow. It is built on spring-mvc. Also support jsf views
http://www.javaworld.com/javaworld/jw-11-2008/jw-11-intro-to-swf2.html
http://www.springsource.org/webflow
http://www.springsource.org/webflow-samples
I see here an example about using jsf with Spring.
Also take a look here.
Maybe it's useful for you.
Is there any reason to use Spring MVC (or other similar frameworks) as a server for GWT RPC? As far as I can tell, 99.9% features of Spring will not be used. Yet, lots of people are looking for best ways to use them together.
Could someone please explain, what are the benefits of using MVC frameworks (on server) with GWT, when all you need on server side is business logic?
I don't see any generally good point in using Spring MVC or another enterprise Java MVC library (like Struts) together with a layer which - as you said - offers only business logic (and therefore can be kept as small and clean as possible).
But Spring itself is way more than just a web (MVC) framework layer and using the dependency injection or AOP features or the ORM API or the Scripting language Groovy (which works fine with Spring) can be a huge benefit for any application.
Spring is much more than just MVC.
Even when you do your UI with GWT, you still need some kind of backend logic.
Things like databases, transactions, security, additional services integrations (emails? SOAP?) and so on.
For this Spring or any other Java server side technology can be a good solution.
As daff said, Spring brings DI + AOP + transactions + many things...
It is useful to have those stuffs managed on your server side with Spring.
Furthermore, the library gwtrpc-spring offers a very convenient way to declare POJOS as rpc services, with the #Service annotation. It avoids declaration of each rpc servlets in the web.xml, as the scan for classes with #Service is automatic.
GWT is just a toolkit, not a framework. If Spring can ease your dev, just use it.
I tend to go for GWT + GIN on the client side and Guice on the server side.
But Spring could just as wel be used for persistance, transactions and organising your business logic on the server side.