Add support for full RESTFul request-mappings to the HTTP inbound adapters [INT-2312]

[spring-operator]

Mark Fisher opened INT-2312 and commented

For more info see Spring-MVC Reference Manual: http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/mvc.html#mvc-ann-requestmapping

---

Reference URL: http://forum.springsource.org/showthread.php?120153

Issue Links:

• A flag to retain default converters when user has customized messageconverters for HttpRequestHandlingController, HttpInboundGateway [INT-3142] #7116 A flag to retain default converters when user has customized messageconverters for HttpRequestHandlingController, HttpInboundGateway
  ("depends on")

• HTTP Adapter URI mappings are sensitive to trailing slashes [INT-3135] #7110 HTTP Adapter URI mappings are sensitive to trailing slashes
  ("is depended on by")

• Avoid Reflection when accessing createRequestMappingInfo in RequestMappingHandlerMapping [INT-3160] #7137 Avoid Reflection when accessing createRequestMappingInfo in RequestMappingHandlerMapping
  ("is depended on by")

• Remove deprecations in HTTP Adapter after upgrade to Spring 3.1.1 [INT-2528] #6507 Remove deprecations in HTTP Adapter after upgrade to Spring 3.1.1

• Move parsers' logic about 'ExpressionFactoryBean' BeanDefinition into 'IntegrationNamespaceUtils' [INT-2619] #6595 Move parsers' logic about 'ExpressionFactoryBean' BeanDefinition into 'IntegrationNamespaceUtils'

2 votes, 6 watchers

[spring-operator]

Artem Bilan commented

Please, look into forum reference: my solution for the author of post was enough.
So, maybe is it as 'Won't fix'?
Or how about my proposition of http-method-router as nested element for http-inbound as additional strategy for request-channel?

[spring-operator]

Mark Fisher commented

I like the approach presented in the forum, and I especially agree with the comment that it helps to alleviate unnecessary duplication of the adapter configuration.

However, I do think we should support the case where someone does want a different adapter that happens to share a path but have a different request method. Maybe it's not urgent enough to include in 2.1 though.

As far as having a "router" within the adapter, that seems like a mix of concerns that we should avoid. Personally, I prefer the approach recommended in the forum to that anyways.

[spring-operator]

Artem Bilan commented

Ok, Mark, thanks.
Some additional question:

that seems like a mix of concerns that we should avoid

And how when do we avoid it in the implementation of Scatter-Gather or Routing Slip?..

[spring-operator]

Mark Fisher commented

Those are "composite" patterns, so by definition they combine concerns (since they are made of multiple components).

However, our HTTP adapters are Channel Adapters or Messaging Gateway components. As such, they should not also be Routers IMO.

[spring-operator]

Mark Fisher commented

I'm moving this issue to 2.2 since the original reporter seems happy with the alternative as recommended in the forum.

It does still seem to be a valid use-case to have more than one adapter with the same path IF you do indeed want other properties that vary (in addition to supported-methods).

However, it is not trivial to support that since we currently rely on the HandlerMapping strategy from the underlying Spring MVC dispatching mechanism. Because of that, we can only return URLs (no requirements for the HTTP method) that map to a particular object, and the adapters are distinct objects. In other words, in Spring MVC, you might have one Controller instance that handles /foo requests but has two different methods for handling GET and POST requests, respectively. That instance can be mapped by the HandlerMapping to "/foo" but it's the responsibility of the HandlerAdapter to determine which method is invoked according to the type of the HTTP request method (GET vs. POST). In our case though that second step is not relevant - rather than mapping first to an object and secondly to a method, we are only mapping to the object (the inbound-channel-adapter or inbound-gateway instance).

[spring-operator]

Artem Bilan commented

Hi, all!

Before starting implementation let me say my thoughts and ask some questions.

I see in the Spring-MVC package org.springframework.web.servlet.mvc.condition and want to follow here with solution from that package and some implementation of org.springframework.web.servlet.mvc.method.RequestMappingInfoHandlerMapping.
However:

1. This package appeared in the Spring 3.1. I see we still stay out from implementation based on Spring 3.1 in our components. Before Spring Integration 3.0. So, how should I act here:

• implement it anyway with Spring-MVC 3.1. Then we have to think of some mechanism to ignore Spring 3.1 feauter from build and tests, when we run SI-2.2 with Spring 3.0
• just wait Spring Integration 3.0.
• or implement our own "condition" support?

2. If you take a look into JavaDocs of org.springframework.web.bind.annotation.RequestMapping you'll see that Spring-MVC supports a lot of Request's requisites to allow use "real REST world", but our HttpRequestHandlingEndpointSupport just supports only "path" (name, id) mapping. And it allows with this issue to support request mapping by "supported-methods" attribute.
   So, how about adding other RESTFul abilities to our http:inbound components?
   Nevertheless this question depends on resolution about support Spring 3.1 right now.

If you decide do not add Spring 3.1 compilation dependency now, I'll try to keep things as simple as posible and will implement some solution only about mappings for "path" and "supported-methods".
Other features and implementation based on 'condition' package we can add in the future in 3.0.
WDYT?

Thanks a lot

[spring-operator]

Artem Bilan commented

Guys, make a decision, please...

[spring-operator]

Oleg Zhurakousky commented

Yes we do indeed want to ensure that SI 2.2 is compatible with Spring 3.0, so whatever approach you take it has to run on 3.0.

[spring-operator]

Artem Bilan commented

Thank you, Oleg.
But maybe we push this issue into 3.0 and don't implement partial solution right now?
And the more: when we come to the 3.0 we're going to refactor this 2.2 solution with Srping-MVC 3.1 to make it more KISS. Right?
What is the reason to hurry up? This issue doesn't have any vote...

[spring-operator]

Artem Bilan commented

Initial refactoring from #6595 will be done during current issue. Implementation will be applied for HTTP endpoints.

[spring-operator]

Artem Bilan commented

A commit for review: artembilan@e1fda68

[spring-operator]

Artem Bilan commented

Issued PR: #723

[spring-operator]

Gunnar Hillert commented

Merged PR

[spring-operator]

Artem Bilan commented

Doesn't work with SPR 3.2.x and above
https://build.springsource.org/browse/INT-SI22SPRING32-388
https://build.springsource.org/browse/INT-MASTERSPRING40-31

[spring-operator]

Artem Bilan commented

PR: #907