Last versions of Spring MVC provide a new way to override default behaviour related to request params with dots and extensions management.
The new configuration strongly depends on concrete project needs and a unique config cannot allow all possibilities.
Overriding this config necessitates to redefine ContentNegotiationManager and/or RequestMappingHandlerMapping that are defaultly defined by mvc:annotation-driven.
Since spring 3.2, mvc:annotation-driven allows to provide a custom ContentNegotiationManager but in many cases, RequestMappingHandlerMapping should also be defined to set a property and this cannot be done with mvc:annotation-driven.
For these reasons and in a general point of view, we need to provide a better way to end users to customize these behaviours and mvc:annotation-driven does not allow this : we need to provide a complete configuration, miror of mvc-annotation-driven behaviour but easier to extend without redefining resthub key features such as Exception mapping.
An alternative to mvc:annotation-driven will allow to implements the last two behaviours without redefining all resthub conf (not even explicitely defined today because of mvc automagic)
That is amazing and something that I'm looking for my project. In my project, I need to know if in the request coming ".json", ".xml" and etc. So, what is the code to get it ?
Alternative to mvc:annotation-driven
Last versions of Spring MVC provide a new way to override default behaviour related to request params with dots and extensions management.
The new configuration strongly depends on concrete project needs and a unique config cannot allow all possibilities.
Overriding this config necessitates to redefine ContentNegotiationManager and/or RequestMappingHandlerMapping that are defaultly defined by mvc:annotation-driven.
Since spring 3.2, mvc:annotation-driven allows to provide a custom ContentNegotiationManager but in many cases, RequestMappingHandlerMapping should also be defined to set a property and this cannot be done with mvc:annotation-driven.
For these reasons and in a general point of view, we need to provide a better way to end users to customize these behaviours and mvc:annotation-driven does not allow this : we need to provide a complete configuration, miror of mvc-annotation-driven behaviour but easier to extend without redefining resthub key features such as Exception mapping.
see :
With such customization, users will be able to finely manage request params with dots :
Consider a controller mapped on "/dot" with these two methods :
The behaviour will be really different depending on the configuration :
Default behaviour (no conf needed)
conf : no
behaviour :
/dot/noDot
will returnnoDot
/dot/noDot.json
will returnnoDot
/dot/noDot.xml
will returnnoDot
/dot/noDot.any
will returnnoDot
/dot/with.dot
will returnwith
/dot/with.dot.json
will returnwith.dot
/dot/with.dot.xml
will returnwith.dot
/dot/dot.included
will returnincluded
/dot/dot.included.json
will returnincluded.json
!!/dot/dot.included.xml
will returnincluded.xml
!!Disable suffixes detection
conf :
useSuffixPatternMatch=false
behaviour :
/dot/noDot
will returnnoDot
/dot/noDot.json
will returnnoDot.json
/dot/noDot.xml
will returnnoDot.xml
/dot/noDot.any
will returnnoDot.any
/dot/with.dot
will returnwith.dot
/dot/with.dot.json
will returnwith.dot.json
/dot/with.dot.xml
will returnwith.dot.xml
/dot/dot.included
will returnincluded
/dot/dot.included.json
will returnincluded.json
/dot/dot.included.xml
will returnincluded.xml
Limit suffixes to registered ones
conf :
useRegisteredSuffixPatternMatch=true
behaviour :
/dot/noDot
will returnnoDot
/dot/noDot.json
will returnnoDot
/dot/noDot.xml
will returnnoDot
/dot/noDot.any
will returnnoDot.any
/dot/with.dot
will returnwith.dot
/dot/with.dot.json
will returnwith.dot
/dot/with.dot.xml
will returnwith.dot
/dot/dot.included
will returnincluded
/dot/dot.included.json
will returnincluded
/dot/dot.included.xml
will returnincluded
An alternative to mvc:annotation-driven will allow to implements the last two behaviours without redefining all resthub conf (not even explicitely defined today because of mvc automagic)
this issue is related to #188