What is the typical use case code that shows the difference between those two annotations - meaning the #RestController and the #RepositoryRestController - ?
According to the annotation the RepositoryRestController is a way to provide custom controllers that still take advantage of Spring Data REST functionality.
Spring Data REST Reference Guide, 15.6. Overriding Spring Data REST Response Handlers:
Sometimes you may want to write a custom handler for a specific
resource. To take advantage of Spring Data REST’s settings, message
converters, exception handling, and more, use the
#RepositoryRestController annotation instead of a standard Spring MVC
#Controller or #RestController.
Most importantly the RepositoryRestController is aware of the Spring Data REST base path and will be served under this base path.
Related
I've been playing around with the concept outlined in this answer, to share a common 'contract' between server and client. I'm trying to use this concept in a Spring MVC application that contains both REST endpoints and a Feign client. The #RequestMappings on the REST endpoints are picked up like normal by Spring, but: it also picks up the #RequestMapping on the abstract API class I use for my Feign client, i.e., in terms of the linked example, I have a UserService and UserClient in my code, and Spring picks up the #RequestMapping in the UserService class.
I don't understand why this happens in the first place, because:
The UserService class is an interface. Why and how does Spring think it can map an endpoint to an interface method?? This will obviously never work.
The package containing UserService is not included in the basePackage list of the #ComponentScan annotation on my Application class
Any clues on how I can convince Spring to just ignore all classes in this package??
So apparently this is a known issue, see this thread for ways to fix it.
I'm relatively new to Spring and I'm a little confused about the tag.
After going through the documentation and looking around different posts it seems like the main use of is that it is required by Spring MVC to dispatch requests to #Controllers.
I created a controller with two requestMappings:
#RequestMapping(method=RequestMethod.GET, value="/health")
#RequestMapping(method=RequestMethod.GET, value="/test")
I tested the web app with and without in the servlet.xml and it doesn't seem like any difference was made with being omitted or not. The requests seemed to still reach my controller just fine.
Can anyone explain to me what exactly that tag is used for?
Thanks in advance!
The support for #Controller and #RequestMapping is provided by Spring by default. However, by enabling mvc:annotation-driven you get support for processing the requests that are mapped to annotated controller methods, such as declarative validation, formatting and conversion service. An excerpt from spring's blog that introduced the new config features
It applies sensible defaults based on what is present in your
classpath. Such defaults include:
Using the Spring 3 Type ConversionService as a simpler and more robust alternative to JavaBeans PropertyEditors
Support for formatting Number fields with #NumberFormat
Support for formatting Date, Calendar, and Joda Time fields with #DateTimeFormat, if Joda Time is on the classpath
Support for validating #Controller inputs with #Valid, if a JSR-303 Provider is on the classpath
Support for reading and writing XML, if JAXB is on the classpath
Support for reading and writing JSON, if Jackson is on the classpath
Another related usefull blog post
If this tag is not added to the XML, then you will have to manually
define the beans for components like HandlerAdapter, HandlerMapping,
Binding Initializer, Request Message converters, etc. This tag helps
registering the following components.
DefaultAnnotationHandlerMapping - This is a HandlerMapping
implementation which maps the HTTP requests to the handler methods
defined using the #RequestMapping annotation.
AnnotationMethodHandlerAdapter - It is responsible for scanning the
controllers to identify methods (and parameters) annotated with #MVC
annotations. It scans and caches handler methods annotated with
#RequestMapping. Also handles the #RequestParam, #ModelAttribute,
#SessionAttributes and #InitBinder annotations.
ConfigurableWebBindingInitializer - The initializer for the Web Data
Binder. Helps in declaratively configuring the Web Binder with
validators, conversion services, property editors, etc.
LocalValidatorFactoryBean - Implements the validator interface and
enables JSR303 validation. This is injected into
ConfigurableWebBindingInitializer.
FormattingConversionServiceFactoryBean - A conversion factory that
returns conversion services for basic objects like date and numbers.
This factory is again injected into ConfigurableWebBindingInitializer.
Support for Message Converters
Finally a more formal definition in the official docs
I'm new to spring 3. I studied several tutorials about springmvc, but I can't separately identify what are the corresponding components for model view and controller?
Like in struts2
model-action class
view-jsp
controller - filterDispatcher
Can anyone help me to identify these components clearly?
In Spring MVC, a Controller is usually a Plain java class annotated with #Controller, a View is anything that implements org.springframework.web.servlet.View and the model is usually a ModelMap, a specialized Map implementation.
In a standard setup, a controller method usually returns either a String or a business object.
If it returns a String, that is interpreted as a path to the view name (JSP, Freemarker etc.). If it is a business object and the method is annotated with #ResponseBody, then content negotiation starts, one of the key features of Spring MVC. Depending on configurable aspects like the Accept: header, the path extension etc. Spring automatically serializes the business object to JSON, XML, PDF etc.
The whole mechanism is explained in the Spring Reference under
Spring MVC: Implementing Controllers
In a Spring MVC application using Sitemesh to decorate my views, I want to inject into every Model a security attribute called sec of type WebSecurityExpressionRoot.
This way I could call hasAnyRole(), hasAuthority()... in all my views so administrators would be presented extra stuff by the underlying templating engine (Thymeleaf BTW).
A custom HandlerInterceptorAdapter with an overridden postHandle(...) seems to be Spring MVC's way of accomplishing this, but it seems that my master Sitemesh decorator is kind of stealing my security attribute, because whenever I try to reference in some views it is null.
BUT only the views rendered after one of my controllers are affected, the ones
mapped with mvc:view-controller do have the sec attribute.
I'm considering writing a Filter to stash sec into the current HttpServletRequest to solve this issue but I'm maybe missing something.
Thanks in advance!
Are you sure the mvc:view-controller views/path are hitting the interceptor?
Also, I don't know about Thymeleaf, but using JSPs (eg, JstlView) makes Spring MVC copy Model into Request attributes (for purposes of rendering the view) -- the fact that Sitemesh also gets the values via request attributes is, I think, a consequence.
I want to know how to use the Filter concept in Spring.
I have web application in that i have lot of jsp pages which has login.jsp is the first page. So user can only go via login.jsp no one can not to access any jsp url directly.
Filters have nothing to do with Spring. Just wire them into your web.xml if you'd like to use them.
You also have the option of implementing security - authentication and authorization - using Spring Security. I'd recommend that you look at that if you want to use Spring to solve this problem.
There's nothing special about Servlet Filters in Spring, but Spring does provide a couple of handy support classes for writing them. The DelegatingFilterProxy lets you use a normal Spring bean as a Filter instance, and OncePerRequestFilter ensures that your filter runs only once per request. (Some app servers can run the filters multiple times based on forwarding and including.)