这是问题的延续 Spring MVC @PathVariable被截断
Spring论坛声明它已经固定(3.2版本)作为ContentNegotiationManager的一部分。请看下面的链接。 https://jira.springsource.org/browse/SPR-6164 https://jira.springsource.org/browse/SPR-7632
在我的应用程序中，带有。com的requestParameter被截断了。
谁能告诉我如何使用这个新功能?如何在xml中配置它?
注:春季论坛- #1 Spring MVC @PathVariable带点(.)会被截断
当前回答
在Spring Boot中，正则表达式解决了这样的问题
@GetMapping("/path/{param1:.+}")
其他回答
在Spring Boot Rest Controller中，我通过以下步骤解决了这些问题:
RestController:
@GetMapping("/statusByEmail/{email:.+}/")
public String statusByEmail(@PathVariable(value = "email") String email){
//code
}
从Rest客户端:
Get http://mywebhook.com/statusByEmail/abc.test@gmail.com/
在spring 4.2的路径名中包含电子邮件地址的完整解决方案是
<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>
<mvc:annotation-driven
content-negotiation-manager="contentNegotiationManager">
<mvc:path-matching suffix-pattern="false" registered-suffixes-only="true" />
</mvc:annotation-driven>
将其添加到应用程序xml中
在Spring Boot中，正则表达式解决了这样的问题
@GetMapping("/path/{param1:.+}")
据我所知，这个问题只出现在请求映射结束时的路径变量。
我们可以通过在requestmapping中定义regex插件来解决这个问题。
/somepath/{variable:.+}
如果您正在使用Spring 3.2+，那么下面的解决方案将有所帮助。这将处理所有的url，所以肯定比在请求URI映射中应用regex模式更好。喜欢/ somepath /{变量:。+}
在xml文件中定义一个bean
<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
<property name="useSuffixPatternMatch" value="false"/>
<property name="useRegisteredSuffixPatternMatch" value="true"/>
</bean>
标志的用法可以在文档中找到。我把剪报解释一下
解释useRegisteredSuffixPatternMatch据说可以解决这个问题。来自类中的java文档
If enabled, a controller method mapped to "/users" also matches to "/users.json" assuming ".json" is a file extension registered with the provided {@link #setContentNegotiationManager(ContentNegotiationManager) contentNegotiationManager}. This can be useful for allowing only specific URL extensions to be used as well as in cases where a "." in the URL path can lead to ambiguous interpretation of path variable content, (e.g. given "/users/{user}" and incoming URLs such as "/users/john.j.joe" and "/users/john.j.joe.json").
