Question is simple, what is the difference between the above dependencies? Does the first one enough for a springboot app or the second contains something special?
Artifact thymeleaf is the Core library.
Artifact thymeleaf-spring4 allows to integrate Thymeleaf with the Spring Framework, especially (but not only) Spring MVC. Btw there are several Thymeleaf integration packages for different Spring versions are available at the moment:
thymeleaf-spring3, thymeleaf-spring4, thymeleaf-spring5.
Information from thymeleaf-spring official documentation:
Thymeleaf offers a set of Spring integrations that allow you to use it as a fully-featured substitute for JSP in Spring MVC applications.
These integrations will allow you to:
Make the mapped methods in your Spring MVC #Controller objects forward to templates managed by Thymeleaf, exactly like you do with JSPs.
Use Spring Expression Language (Spring EL) instead of OGNL in your templates.
Create forms in your templates that are completely integrated with your form-backing beans and result bindings, including the use of property editors, conversion services and validation error handling.
Display internationalization messages from message files managed by Spring (through the usual MessageSource objects).
Resolve your templates using Spring’s own resource resolution mechanisms.
If you use Spring Boot, you can just use the spring-boot-starter-thymeleaf dependency. It already contains the above two dependencies as well as some others.
Related
Here, several questions have been asked by many developers about difference between Spring-Rest and JAX-RS.
And, I have also learned that Spring is not following any specification and Spring framework has their own implementation then
Why Spring allows all that Annotations which are supported/used by JAX-RS by default?
Spring does not support JAX-RS annotations. If there is a situation where you think they do, then you are mistaken or it's just a coincidence. Period. If you will add any JAX-RS annotations in my Spring MVC program, nothing will happen. Annotations are just metadata. They are not programs. If Spring does not recognize the metadata, it will ignore it. But if you use a JAX-RS annotation in place of a Spring annotation that is used for the same purpose, respective of their framework, then you will not get the expected Spring behavior. So basically, if you are using Spring MVC, remove any JAX-RS dependencies so you don't mistakenly use them.
So I'm about to learn Spring MVC. But what I don't understand is why should I use Spring MVC if I can implement the MVC pattern using a single servlet conroller and JSPs? What advantages does Spring MVC provide over simple java MVC pattern?
Actually yes, you can do it. Question is if you should do it. Spring MVC gives you better organization of your code.
Pure MVC Frameworks like Spring MVC are obsolete today. When combined with templating engines like Thymeleaf, it lacks functionality and developers usually reinvent JSF. For single-page apps based on some popular JS frameworks that need REST backend, JAX-RS is way cleaner and better than Spring MVC REST.
So no, today you don't need Spring MVC and can stick with pure Java EE. For simple, toy-like applications where servlets are enough, you don't really need it but it may be better to use it. For anything serious, MVC is outdated and Spring has nothing to offer.
Edit 2017: Spring offers JAX-RS integration. However, it has several pitfalls, for example Spring won't automatically register classes annotated with #Path for you. Details can be found in Dzone Article
The best way to realize that it's better to play with these technologies for yourself, if you want to try spring MVC I recommend you start with spring boot because you can create projects with more agility without configuring xml files
Spring Boot
Some Features
Create stand-alone Spring applications
Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
Provide opinionated 'starter' POMs to simplify your Maven configuration
Automatically configure Spring whenever possible
Provide production-ready features such as metrics, health checks and
externalized configuration
Absolutely no code generation and no requirement for XML configuration
One of the ideas applied in Spring (not invented by Spring) is
Do not reinvent a wheel.
Having a single controller is not a good idea I'd say - breaking separation of concerns principle.
You can learn more about MVC from Spring documentation.
I am currently implementing a small Spring MVC PoC, and I would like to use JSF as the view technology since most people in my company are used to a J2EE with Primefaces environment.
Does Spring MVC 3 support JSF, or simply JSP? I have read multiple articles mixing the two.
My need is to create an appealing UI. Is there a simple way to do this using Spring MVC with the JSP as the view technology?
Our application uses schedules/calendars in multiples pages. It's basically a time management APP
You're making a conceptual mistake. JSF is not a view technology. JSF is a MVC framework. Exactly like as Spring MVC, albeit they have both a different ideology; JSF is component based MVC and Spring MVC is request based MVC. Thus they are full competitors. You cannot mix them. You should choose the one or the other. Instead, JSP and Facelets are true view technologies. Since Java EE 6 (December 2009), JSP is deprecated and replaced by Facelets (XHTML) as default view technology for JSF.
You can use Spring MVC with JSP view technology. You can also use Spring MVC with Facelets view technology (and many others). But you can not use Spring MVC with JSF components let alone with JSF component libraries like PrimeFaces. JSF output components may work, but JSF input components won't work at all. Spring MVC has already its own <form:xxx> tags for input. Even if you mix them, you will end up with half of the functionality from both frameworks in a mingled and confusing code base. This is not making any sense. If all you want is to use the same UI as PrimeFaces, just grab jQuery UI. It's also exactly what PrimeFaces is using under the covers. PrimeFaces is a jQuery-based JSF component library.
From the other side on, it can also be very good that you confused Spring IoC/DI with Spring MVC. Spring IoC/DI is in turn usable together with JSF. You can replace the JSF managed bean facility (#ManagedBean and friends) by Spring managed bean facility (#Component and friends), usually with the sole purpose in order to use #Autowired in a JSF backing bean. But that's it. The JSF MVC framework lifecycle, the JSF components and the view technology remain unchanged. The standard Java EE equivalent of that would be using CDI (and EJB).
The same story applies to Spring Security. You can use it together with JSF, you should however not follow Spring Security + Spring MVC targeted documentation/examples in order to configure it, but only Spring Security + JSF ones. Do note that Spring Security constraints on business actions only works when you replace the JSF managed bean facility by Spring managed bean facility. So that would still require a "Integrate Spring in JSF" as described in previous paragraph. The standard Java EE equivalent of this all would be using container managed security (JAAS/JASPIC) via <security-constraint> entries in web.xml.
The same story also applies to Spring WebFlow. You only also need to make sure that you're using most recent version of Spring WebFlow as older versions cause conflicts when used together with multiple JSF component libraries. Moreover, since JSF 2.2, new Faces Flows feature was introduced as part of standard Java EE API, hereby basically making Spring WebFlow superfluous.
Then there is Spring Boot. This does not have a direct equivalent in Java EE. Spring Boot basically enables you to execute a Java EE application using a plain Java application class with a main() method "in an easy and abstract way". Without Spring Boot it's surely possible (otherwise Spring Boot would never have existed), it's only a bit more work as to configuration as you have to take into account server-specific details based on its documentation. For example: Undertow and Jetty.
Coming back to JSF and Spring MVC, if really necessary, you can safely run Spring MVC and JSF next to each other in same web application, but they won't interoperate in server side. They will run completely independently. They will at most touch each other in the client side, if some JavaScript in a JSF-generated HTML page happens to invoke a Spring based REST web service call in the same web application. But that Spring web service would then not need/have to know anything about JSF in order to respond accordingly. The standard Java EE equivalent of that Spring REST webservice is JAX-RS.
The upcoming Java EE 8 will come with a new request based MVC framework, named just "MVC", based on lessons of both JSF and Spring MVC, hereby supplanting Spring MVC and providing a standard alternative to JSF.
See also:
What exactly is Java EE?
Difference between Request MVC and Component MVC
What are the main disadvantages of Java Server Faces 2.0?
What is the need of JSF, when UI can be achieved from CSS, HTML, JavaScript, jQuery?
When is it necessary or convenient to use Spring or EJB3 or all of them together?
Spring JSF integration: how to inject a Spring component/service in JSF managed bean?
Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
Spring MVC and JSF don't really mix. You can use JSF for the view related stuff and have Spring manage and wire the backed (services, daos etc.). But trying to match #Controllers with JSF pages isn't something that really works nicely (next to that both are different stacks request based against component-based).
To integrate Spring with JSF you will need to add the SpringBeanFacesELResolver to your faces-config.xml. That will lookup beans from Springs application context. For this to work you have to use plain JSF annotations and not the CDI based annotations.
Spring Webflow can be a help here. Check out this sample project.
https://github.com/spring-projects/spring-webflow-samples/tree/master/primefaces-showcase
As blogged on spring.io both Spring 4.1 and Sprig Boot will integrate the new Groovy template engine (https://spring.io/blog/2014/05/28/using-the-innovative-groovy-template-engine-in-spring-boot, http://spring.io/blog/2014/07/28/spring-framework-4-1-spring-mvc-improvements).
I wonder the following:
Will Spring provide something like it does with the Spring Forms and Spring Security taglib?
If not what would be best to e.g. render form fields and more importantly form errors?
I think without it it will be a step back to develop a traditional Spring MVC webapp.
The template engine suports something like a BaseTemplate (see http://mrhaki.blogspot.nl/2014/08/groovy-goodness-use-custom-template.html) where it would be possible to provide custom methods to the template engine.
Related to this:
You can only provdide a single base template, so it will be difficult to include methods from multiple extension points. E.g. Spring Forms, Spring Security and multiple custom extensions like Fontawesome.
Is it possible to set the base template with Spring Boot?
A simple way to expose a lot of the spring specific attributes csrf etc... is to include spring.groovy.template.expose-request-attributes = true in your application.properties
I am currently implementing a small Spring MVC PoC, and I would like to use JSF as the view technology since most people in my company are used to a J2EE with Primefaces environment.
Does Spring MVC 3 support JSF, or simply JSP? I have read multiple articles mixing the two.
My need is to create an appealing UI. Is there a simple way to do this using Spring MVC with the JSP as the view technology?
Our application uses schedules/calendars in multiples pages. It's basically a time management APP
You're making a conceptual mistake. JSF is not a view technology. JSF is a MVC framework. Exactly like as Spring MVC, albeit they have both a different ideology; JSF is component based MVC and Spring MVC is request based MVC. Thus they are full competitors. You cannot mix them. You should choose the one or the other. Instead, JSP and Facelets are true view technologies. Since Java EE 6 (December 2009), JSP is deprecated and replaced by Facelets (XHTML) as default view technology for JSF.
You can use Spring MVC with JSP view technology. You can also use Spring MVC with Facelets view technology (and many others). But you can not use Spring MVC with JSF components let alone with JSF component libraries like PrimeFaces. JSF output components may work, but JSF input components won't work at all. Spring MVC has already its own <form:xxx> tags for input. Even if you mix them, you will end up with half of the functionality from both frameworks in a mingled and confusing code base. This is not making any sense. If all you want is to use the same UI as PrimeFaces, just grab jQuery UI. It's also exactly what PrimeFaces is using under the covers. PrimeFaces is a jQuery-based JSF component library.
From the other side on, it can also be very good that you confused Spring IoC/DI with Spring MVC. Spring IoC/DI is in turn usable together with JSF. You can replace the JSF managed bean facility (#ManagedBean and friends) by Spring managed bean facility (#Component and friends), usually with the sole purpose in order to use #Autowired in a JSF backing bean. But that's it. The JSF MVC framework lifecycle, the JSF components and the view technology remain unchanged. The standard Java EE equivalent of that would be using CDI (and EJB).
The same story applies to Spring Security. You can use it together with JSF, you should however not follow Spring Security + Spring MVC targeted documentation/examples in order to configure it, but only Spring Security + JSF ones. Do note that Spring Security constraints on business actions only works when you replace the JSF managed bean facility by Spring managed bean facility. So that would still require a "Integrate Spring in JSF" as described in previous paragraph. The standard Java EE equivalent of this all would be using container managed security (JAAS/JASPIC) via <security-constraint> entries in web.xml.
The same story also applies to Spring WebFlow. You only also need to make sure that you're using most recent version of Spring WebFlow as older versions cause conflicts when used together with multiple JSF component libraries. Moreover, since JSF 2.2, new Faces Flows feature was introduced as part of standard Java EE API, hereby basically making Spring WebFlow superfluous.
Then there is Spring Boot. This does not have a direct equivalent in Java EE. Spring Boot basically enables you to execute a Java EE application using a plain Java application class with a main() method "in an easy and abstract way". Without Spring Boot it's surely possible (otherwise Spring Boot would never have existed), it's only a bit more work as to configuration as you have to take into account server-specific details based on its documentation. For example: Undertow and Jetty.
Coming back to JSF and Spring MVC, if really necessary, you can safely run Spring MVC and JSF next to each other in same web application, but they won't interoperate in server side. They will run completely independently. They will at most touch each other in the client side, if some JavaScript in a JSF-generated HTML page happens to invoke a Spring based REST web service call in the same web application. But that Spring web service would then not need/have to know anything about JSF in order to respond accordingly. The standard Java EE equivalent of that Spring REST webservice is JAX-RS.
The upcoming Java EE 8 will come with a new request based MVC framework, named just "MVC", based on lessons of both JSF and Spring MVC, hereby supplanting Spring MVC and providing a standard alternative to JSF.
See also:
What exactly is Java EE?
Difference between Request MVC and Component MVC
What are the main disadvantages of Java Server Faces 2.0?
What is the need of JSF, when UI can be achieved from CSS, HTML, JavaScript, jQuery?
When is it necessary or convenient to use Spring or EJB3 or all of them together?
Spring JSF integration: how to inject a Spring component/service in JSF managed bean?
Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
Spring MVC and JSF don't really mix. You can use JSF for the view related stuff and have Spring manage and wire the backed (services, daos etc.). But trying to match #Controllers with JSF pages isn't something that really works nicely (next to that both are different stacks request based against component-based).
To integrate Spring with JSF you will need to add the SpringBeanFacesELResolver to your faces-config.xml. That will lookup beans from Springs application context. For this to work you have to use plain JSF annotations and not the CDI based annotations.
Spring Webflow can be a help here. Check out this sample project.
https://github.com/spring-projects/spring-webflow-samples/tree/master/primefaces-showcase