Externalized request mapping as a 1st class alternative to @RequestMapping [SPR-5757]

[spring-projects-issues]

Vijay Natarajan opened SPR-5757 and commented

While I am not averse to having the controllers use annotation based configuration, I would love to see a functionally equivalent XML based routing configuration, for those who would rather not use it. The current model, IMHO, has the following problems:

1. URL mapping is scattered all over the place. If I have 15 controllers, with 10 methods each (and note that there's the issue of each method potentially having a completely different URL that it can match), a newbie would have to look at 150 potential places to map a given URL to the controller action it resolves to. Admittedly, having good conventions and oversight will alleviate this problem, but seems too easy to have things go awry.

2. any changes to the mapping requires a recompile.

3. The same controller method cannot be mapped to multiple urls (or at least I can't figure out how to do it :( ), allowing different views to be driven by the same controller.

4. A somewhat minor thing. There is now way to write a controller w/o Spring dependencies.

Btw, It would be nice to have mappings that are pattern based, such as, a way to map /somepath/{method} to handler SomePathController, method {method}.

http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/

---

Affects: 3.0.5

Attachments:

• ShowRequestMappings.png (34.90 kB)

Issue Links:

• Allow customization of request mappings [SPR-9935] #14568 Allow customization of request mappings
• Allow links to @Controller methods from views without hardcoding URLs [SPR-5779] #10449 Allow links to @Controller methods from views without hardcoding URLs
• Overloaded @PathVariable based handler methods fail with ambiguity when URL mapping is specified in XML [SPR-7654] #12310 Overloaded @PathVariable based handler methods fail with ambiguity when URL mapping is specified in XML ("supersedes")

12 votes, 21 watchers

[spring-projects-issues]

Arjen Poutsma commented

Since you copy-pasted this issue from a comment on my blog post, it seems appropriate to copy-paste my answer here :):

Ad 1 & 2: Rossen wrote a post about combining XML and annotations a while ago. They key idea is to use XML for the course-grainined mappings, and annotations for further disambiguation. Check it out!

Ad 3:The @RequestMapping annotation allows for multiple paths as a String array, so you can map multiple urls to the same controller method.

Ad 4: It was never possible to write a controller for MVC without having Spring dependencies. Previously, you had to implement the controller interface, or extend from one of the base classes. I would say that the Spring dependency has become less with @MVC, now that we use annotations, since these are only necessary at compile time, not at runtime.

[spring-projects-issues]

Vijay Natarajan commented

:-)

It turns out it's not sufficient that I look at the post for comments every day, I apparently also have to refresh the page from the server once in a while!!! Who'd have thunk? :-D

Anyway, sorry about that and thanks for the response.

Ad 1 & 2: I read Rossen's post, and it was good to see the information there. However, those features address neither problems I pointed.
Not having everything in one place is still a problem. I don't have a single place to figure out my routing. And there's still some changes that will require recompiling.

Ad 3: Oh, cool! But could you consider this feature "It would be nice to have mappings that are pattern based, such as, a way to map /somepath/{method} to handler SomePathController, method {method}" ie. a single RequestMapping at say the class level which let's me specify that a portion of the uri maps to a method name.

Ad 4. Sure, agreed. I think those improvements are fantastic. However, given that we can pretty much configure everything with annotations, I'd submit that having equivalent XML would eliminate even the compile time dependency. (Note: This is not causing me any trouble at all, as I don't care about not having spring dependencies. Why should I? :) But reduced coupling is always better, no? )

Vijay

[spring-projects-issues]

David Sledge commented

I'd, also, like to see a third XML-based option for defining controllers with the same level of configuration detail as the annotations. Take the the EditPetForm class referenced in 13.11. Annotation-based controller configuration for instance. Strip out the annotations, and I'd imagine that the XML configuration I would look something like the following:

<bean id="editPetFormController" autowire="constructor"
    class="org.springframework.samples.petclinic.web.EditPetForm" />

<webmvc:controller refid="helloController" request-mapping="/editPet.do">
  <handler method="poplatePetTypes" model-attr="types"/>
  <handler method="setupForm" request-method="get">
    <arg type="int" request-param="petId" />
    <arg type="org.springframework.ui.ModelMap" />
  </handler>
  <handler method="processSubmit" request-method="post">
    <arg type="org.springframework.samples.petclinic.Pet" model-attr="pet" />
    <arg type="org.springframework.validation.BindingResult" />
    <arg type="org.springframework.web.bind.support.SessionStatus" />
  </handler>
</webmvc:controller>

To reiterate what was said previously, this would help decouple the application from the framework. Ideally, I'd like to reduce number of import org.springframework.[...]; statements in my application to zero. I've recently started using Spring Web-MVC and was surprised that there wasn't something like this already in place.

[spring-projects-issues]

Blurbee commented

I totally agree with David. The annotation and XML based configuration must have feature parity.

Vijay brought up a very critical point that I would like to keep all my mapping in one file. I just ran into while evaluating spring framework for my project. In fact it is mentioned as a drawback of annotations in the documentation.

For users who have already gone down the path of RequestMapping, they should be able to refactor the base URL as a parameter:
So, developers can change @RequestMapping("/hardcodedbase/....") to @RequestMapping("<baseuri>/...") and the base uri must be definable in the XML configuration.

[spring-projects-issues]

Ilya Kazakevich commented

I believe that everything you can do using annotations you also should be able to do using XML.
It is very strange that spring has no such functionality.

Imagine yourself a really huge project with 200 controllers. Do you want your mappings to be spread across them?

Param-to-property mapping (as they have in struts) could be nice too, but in such case controller has to be request-scoped, not singleton.

[spring-projects-issues]

Rossen Stoyanchev commented

Something that isn't going to address this issue but is worth knowing is the ability to see all request mappings in the STS @RequestMappings view. Sort by Resource URL, Request Method, and controller method. Start typing a resource URL to get to the first match. Double-click to jump to the selected controller method. Attached is a screenshot.

[spring-projects-issues]

Rossen Stoyanchev commented

We can consider this for 3.2. In the mean time, for anyone interested it should be fairly simple to build a RequestMappingHandlerMapping variant that supplies request mapping information from external configuration rather than from annotations.

[spring-projects-issues]

Rossen Stoyanchev commented

Spring Social could benefit from same way of externalizing request mapping configuration. It has a ConnectController, which is mapped to "/connect". Applications using Spring Social may wish to customize or override the URL in its class-level @RequestMapping.

[spring-projects-issues]

Rossen Stoyanchev commented

Modified title (was: "XML Based Request mapping with path variables") to reflect more accurately what is being requested vs how it will be implemented..

[spring-projects-issues]

Dennis Homann commented

The ability to externalize the request mapping would be of great benefit.

Externalization should be the focus, not necessarily the definition of mappings in XML.
I could also imagine a DSL-style approach similar to RoR's routes.rb or conf/routes in the Play framework.

For instance, if the framework separated the mapping configuration from its execution and provide a convenience configuration builder to be used from XML, we could then just roll our own mapping configurators as needed.

[spring-projects-issues]

Rossen Stoyanchev commented

I've created #14568 to track the case of customized @RequestMapping path patterns separate from the support for externalized request mappings requested here.

[spring-projects-issues]

Ilya Kazakevich commented

Hello Rossen,

I use Intellij IDEA which is pretty popular Java IDE:) It does not have "show all request mapping" feature afaik. And if I write my own xml-based RequestMappingHandlerMapping it would not be supported by Idea too. Idea helps me to write struts.xml, but it would not help me with my custom xml. No static checking.
So the only way to make SpringMVC as friendly for IDEA users as Struts is, we definitely need officially supported xml-based RequestMappingHandlerMapping:)

[spring-projects-issues]

Jakub Jirutka commented

Yeah, absolutely! I like Spring a lot for its great XML-based configuration support. Why we still cannot configure request mappings in XML? :(

[spring-projects-issues]

Ilya Kazakevich commented

Moving it to "General backlog" means you would not implement it in 3.2 version?:(

[spring-projects-issues]

Rossen Stoyanchev commented

Ilya Kazakevich, yes 3.2 will be released very soon.

I agree with the Dennis Homann's comment the goal is externalized request mappings, be it XML or not. The springmvc-router project is one example of an alternative. The syntax is very short, which is important for 200+ controllers, and the ability to name a route from a view is very compelling.

Also the ability to externalize or view all request mappings has been available since 3.1. It can be provided in the form of org.springframework.web.servlet.mvc.method.RequestMappingInfo from any source, not just annotations. Projects like springmvc-router and swagger-springmvc are proof of that as they build on this very mechanism.

The question really is what form of externalized request mappings to provide explicit support for within Spring MVC. Providing an XML namespace like the one David Sledge showed is relatively trivial to create and plug in even today.

[spring-projects-issues]

Jakub Jirutka commented

Rossen Stoyanchev,

well, if it’s so simple to provide an XML namespace config for requests mapping (that’s all what I want… and believe that also many others), why it’s not gonna be in 3.2?

Sure, each of us can write it yourself… or write very own framework… but why? We need the only one standard namespace, from Spring. Look at Spring Security, there are many specialized namespaces and it’s great.

I don’t think that XML is the only way either. The springmvc-router looks good, but the standard way in Spring are XML configs, aren’t they? I mean that there should be the XML namespace for that and then we can have something like springmvc-router (and annotations) as an alternative.

As you wrote, in the case of hundreds controllers, XML is too verbose. Agree. However, in case of some tiny module where I need only few “endpoints”, I would like to have all config in one place along with beans, security etc.

[spring-projects-issues]

Rossen Stoyanchev commented

Jakub Jirutka, point taken. It is simple in terms of we know how it can be plugged in but it would take a number of iterations to design a usable and complete XML namespace. Why is it not in 3.2? We simply didn't get to it. Just look in JIRA and Github to see the amount of work that goes on and is requested all the time. This is why we have a contribution process in place and when you really care about something, you can help move it forward.

[spring-projects-issues]

Artem Bilan commented

Guys!

Spring Integration since 3.0 provides the required solution:
http://docs.spring.io/spring-integration/docs/3.0.0.BUILD-SNAPSHOT/reference/html/whats-new.html#3.0-request-mapping
https://github.com/spring-projects/spring-integration/blob/master/spring-integration-http/src/test/java/org/springframework/integration/http/inbound/Int2312RequestMappingIntegrationTests-context.xml
It will be available in the upcoming Spring Integration RC1

Cheers,
Artem

[spring-projects-issues]

Rossen Stoyanchev commented

I am resolving this as "Won't Fix" in recognition of the fact that we won't pursue this option. When @RequestMapping was first introduced we did support a combination of XML mappings routing to the class + method level resolution via annotations. That lead to many practical issues and eventually to the complete re-write of @RequestMapping infrastructure in Spring Framework 3.1 such that request mappings are purely annotation-based and resolved 100% within the HandlerMapping resolving to a specific method. Technically this new infrastructure allows for completely replacing annotations and populating a RequestMappingInfo from any metadata (like XML or other configuration) but that leads to lots of challenges in supporting references to methods in external configuration.

Spring Framework 5 has a JDK 8+ baseline and supports a new functional, web framework that allows defining request mappings in the form of routing functions (see introduction). Since the handler is a functional interface it allows for the use of method references. While I wouldn't claim that approach fulfills the requirements for this ticket, it does provide an alternative programming model in which fine-grained request mappings can be expressed more naturally without annotations.