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.