Spring considère que tout ce qui se trouve derrière le dernier point est une extension de fichier telle que .json ou .xml et le tronquer pour récupérer votre paramètre.
Donc si vous avez /{blahName} :
-
/param , /param.json , /param.xml ou /param.anything donnera lieu à un paramètre avec la valeur param
-
/param.value.json , /param.value.xml ou /param.value.anything donnera lieu à un paramètre avec la valeur param.value
Si vous modifiez votre mappage en /{blahName:.+} comme suggéré, tout point, y compris le dernier, sera considéré comme faisant partie de votre paramètre :
-
/param donnera lieu à un paramètre avec la valeur param
-
/param.json donnera lieu à un paramètre avec la valeur param.json
-
/param.xml donnera lieu à un paramètre avec la valeur param.xml
-
/param.anything donnera lieu à un paramètre avec la valeur param.anything
-
/param.value.json donnera lieu à un paramètre avec la valeur param.value.json
- ...
Si vous ne vous souciez pas de la reconnaissance des extensions, vous pouvez la désactiver en surchargeant la fonction mvc:annotation-driven automatique :
<bean id="handlerMapping"
class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
<property name="contentNegotiationManager" ref="contentNegotiationManager"/>
<property name="useSuffixPatternMatch" value="false"/>
</bean>
Donc, encore une fois, si vous avez /{blahName} :
-
/param , /param.json , /param.xml ou /param.anything donnera lieu à un paramètre avec la valeur param
-
/param.value.json , /param.value.xml ou /param.value.anything donnera lieu à un paramètre avec la valeur param.value
Remarque : la différence avec la configuration par défaut n'est visible que si vous disposez d'un mappage tel que /something.{blahName} . Voir Problème du projet Resthub .
Si vous souhaitez conserver la gestion des extensions, depuis Spring 3.2, vous pouvez également définir la propriété useRegisteredSuffixPatternMatch du bean RequestMappingHandlerMapping afin de conserver la reconnaissance des suffixes activée mais limitée aux extensions enregistrées.
Ici, vous définissez uniquement les extensions json et xml :
<bean id="handlerMapping"
class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
<property name="contentNegotiationManager" ref="contentNegotiationManager"/>
<property name="useRegisteredSuffixPatternMatch" value="true"/>
</bean>
<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
<property name="favorPathExtension" value="false"/>
<property name="favorParameter" value="true"/>
<property name="mediaTypes">
<value>
json=application/json
xml=application/xml
</value>
</property>
</bean>
Notez que mvc:annotation-driven accepte maintenant une option contentNegotiation pour fournir un bean personnalisé mais la propriété de RequestMappingHandlerMapping doit être changée en true (default false) (cf. https://jira.springsource.org/browse/SPR-7632 ).
Pour cette raison, vous devez toujours surcharger toute la configuration mvc:annotation-driven. J'ai ouvert un ticket à Spring pour demander un RequestMappingHandlerMapping personnalisé : https://jira.springsource.org/browse/SPR-11253 . Veuillez voter si vous êtes intéressé par.
Lors de la substitution, veillez à prendre également en compte la substitution de la gestion des exécutions personnalisées. Sinon, tous vos mappages d'exceptions personnalisés échoueront. Vous devrez réutiliser les messageCoverters avec un list bean :
<bean id="validator" class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean" />
<bean id="conversionService" class="org.springframework.format.support.FormattingConversionServiceFactoryBean" />
<util:list id="messageConverters">
<bean class="your.custom.message.converter.IfAny"></bean>
<bean class="org.springframework.http.converter.ByteArrayHttpMessageConverter"></bean>
<bean class="org.springframework.http.converter.StringHttpMessageConverter"></bean>
<bean class="org.springframework.http.converter.ResourceHttpMessageConverter"></bean>
<bean class="org.springframework.http.converter.xml.SourceHttpMessageConverter"></bean>
<bean class="org.springframework.http.converter.xml.XmlAwareFormHttpMessageConverter"></bean>
<bean class="org.springframework.http.converter.xml.Jaxb2RootElementHttpMessageConverter"></bean>
<bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter"></bean>
</util:list>
<bean name="exceptionHandlerExceptionResolver"
class="org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver">
<property name="order" value="0"/>
<property name="messageConverters" ref="messageConverters"/>
</bean>
<bean name="handlerAdapter"
class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter">
<property name="webBindingInitializer">
<bean class="org.springframework.web.bind.support.ConfigurableWebBindingInitializer">
<property name="conversionService" ref="conversionService" />
<property name="validator" ref="validator" />
</bean>
</property>
<property name="messageConverters" ref="messageConverters"/>
</bean>
<bean id="handlerMapping"
class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
</bean>
J'ai implémenté, dans le projet open source Resthub dont je fais partie, un ensemble de tests sur ces sujets : voir https://github.com/resthub/resthub-spring-stack/pull/219/files et https://github.com/resthub/resthub-spring-stack/issues/217
0 votes
Il semble que cela ait été résolu dans Spring 3.2-M2 : voir Permet de spécifier des chemins d'extension de fichier valides pour la négociation du contenu. et sa documentation .