Spring MVC @PathVariable mit Punkt (.) wird abgeschnitten

Question

Dies ist eine Fortsetzung der Frage Spring MVC @PathVariable wird abgeschnitten

Das Spring-Forum gibt an, dass es behoben wurde (Version 3.2) als Teil des ContentNegotiationManagers. Weitere Informationen finden Sie unter dem folgenden Link.
https://jira.springsource.org/browse/SPR-6164
https://jira.springsource.org/browse/SPR-7632

In meiner Anwendung wird die Anforderungsparameter mit .com abgeschnitten.

Kann mir jemand erklären, wie man dieses neue Feature verwendet? Wie wird es in XML konfiguriert?

Hinweis: Spring-Forum- #1 Spring MVC @PathVariable mit Punkt (.) wird abgeschnitten

Answer 1

Soweit ich weiß, tritt dieses Problem nur beim Pathvariable am Ende des RequestMappings auf.

Wir konnten das Problem lösen, indem wir das Regex-Add-On im RequestMapping definiert haben.

/somepath/{variable:.+}

Answer 2

Spring betrachtet alles hinter dem letzten Punkt als Dateierweiterung, wie z.B. .json oder .xml und kürzt es ab, um Ihren Parameter abzurufen.

Also, wenn Sie /somepath/{variable} haben :

• /somepath/param, /somepath/param.json, /somepath/param.xml oder /somepath/param.anything führen zu einem Parameter mit dem Wert param
• /somepath/param.value.json, /somepath/param.value.xml oder /somepath/param.value.anything führen zu einem Parameter mit dem Wert param.value

Wenn Sie Ihre Zuordnung auf /somepath/{variable:.+} ändern, wie vorgeschlagen, wird jeder Punkt, einschließlich des letzten, als Teil Ihres Parameters betrachtet:

• /somepath/param führt zu einem Parameter mit dem Wert param
• /somepath/param.json führt zu einem Parameter mit dem Wert param.json
• /somepath/param.xml führt zu einem Parameter mit dem Wert param.xml
• /somepath/param.anything führt zu einem Parameter mit dem Wert param.anything
• /somepath/param.value.json führt zu einem Parameter mit dem Wert param.value.json
• ...

Wenn Sie die Erweiterungserkennung nicht benötigen, können Sie sie deaktivieren, indem Sie mvc:annotation-driven automatisch überschreiben:

Also, wieder, wenn Sie /somepath/{variable} haben :

• /somepath/param, /somepath/param.json, /somepath/param.xml oder /somepath/param.anything führen zu einem Parameter mit dem Wert param
• /somepath/param.value.json, /somepath/param.value.xml oder /somepath/param.value.anything führen zu einem Parameter mit dem Wert param.value

Hinweis: Der Unterschied von der Standardkonfiguration ist nur sichtbar, wenn Sie eine Zuordnung wie somepath/something.{variable} haben. siehe Resthub-Problemmeldung

Wenn Sie die Erweiterungsverwaltung beibehalten möchten, können Sie seit Spring 3.2 auch die Eigenschaft useRegisteredSuffixPatternMatch des RequestMappingHandlerMapping-Beans festlegen, um die Erkennung des Suffixmusters aktiviert zu lassen, jedoch auf registrierte Erweiterungen beschränkt.

Hier definieren Sie nur die json- und xml-Erweiterungen :

            json=application/json
            xml=application/xml

Beachten Sie, dass mvc:annotation-driven jetzt eine contentNegotiation-Option akzeptiert, um ein benutzerdefiniertes Bean bereitzustellen, jedoch muss die Eigenschaft des RequestMappingHandlerMapping-Beans auf true geändert werden (standardmäßig false) (vgl. https://jira.springsource.org/browse/SPR-7632).

Aus diesem Grund müssen Sie immer noch die gesamte Konfiguration von mvc:annotation-driven überschreiben. Ich habe ein Ticket bei Spring eröffnet, um nach einem benutzerdefinierten RequestMappingHandlerMapping zu fragen: https://jira.springsource.org/browse/SPR-11253. Bitte stimmen Sie ab, wenn Sie daran interessiert sind.

Beim Überschreiben sollten Sie auch die benutzerdefinierte Ausführungsverwaltung in Betracht ziehen. Andernfalls schlagen alle benutzerdefinierten Exception-Zuordnungen fehl. Sie müssen messageConverters mit einem Listen-Bean wiederverwenden:

Ich habe, im Open-Source-Projekt Resthub, an dem ich beteiligt bin, eine Reihe von Tests zu diesen Themen implementiert. Siehe https://github.com/resthub/resthub-spring-stack/pull/219/files & https://github.com/resthub/resthub-spring-stack/issues/217

Answer 3

Update für Spring 4: Seit 4.0.1 können Sie PathMatchConfigurer verwenden (über Ihren WebMvcConfigurer), z.B.

@Configuration
protected static class AllResources extends WebMvcConfigurerAdapter {

    @Override
    public void configurePathMatch(PathMatchConfigurer matcher) {
        matcher.setUseRegisteredSuffixPatternMatch(true);
    }

}

@Configuration
public class WebConfig implements WebMvcConfigurer {

   @Override
   public void configurePathMatch(PathMatchConfigurer configurer) {
       configurer.setUseSuffixPatternMatch(false);
   }
}

In XML wäre es (https://jira.spring.io/browse/SPR-10163):

    [...]

Answer 4

Zusätzlich zur Antwort von Martin Frey kann dieses Problem auch behoben werden, indem am Ende des RequestMapping-Werts ein abschließender Schrägstrich hinzugefügt wird:

/pfad/{variable}/

Beachten Sie, dass dieser Fix die Wartbarkeit nicht unterstützt. Es erfordert jetzt, dass alle URIs einen abschließenden Schrägstrich haben - etwas, das API-Benutzern / neuen Entwicklern möglicherweise nicht offensichtlich ist. Da es wahrscheinlich ist, dass nicht alle Parameter in ihnen ein . haben, können auch intermittierende Fehler auftreten

Answer 5

In Spring Boot Rest Controller habe ich diese durch folgende Schritte gelöst:

RestController :

@GetMapping("/statusByEmail/{email:.+}/")
public String statusByEmail(@PathVariable(value = "email") String email){
  //code
}

Und vom Rest-Client aus:

Get http://mywebhook.com/statusByEmail/abc.test@gmail.com/