SpringCloud/spring-cloud-stream
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove BinderAwareChannelResolver

Browse Source 
We deprecated BinderAwareChannelResolver in 3.0.0 in preference to
spring.cloud.stream.sendto.destination and then later on StreamBridge.
Remove BinderAwareChannelResolver and it's related components completely in 4.0.x.
This commit is contained in:
Soby Chacko
2022-01-07 15:31:32 -05:00
parent 664ee9291a
commit be5b2df1f8
18 changed files with 160 additions and 634 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/src/main/asciidoc/preface.adoc
View File

@@ -166,7 +166,6 @@ compatibility you can still bring `spring-cloud-stream-reactive` from previous v
- _Test support binder_ `spring-cloud-stream-test-support` with MessageCollector in favor of a new test binder. See <<Testing>> for more details.
- _@StreamMessageConverter_ - deprecated as it is no longer required.
- The `original-content-type` header references have been removed after it's been deprecated in v2.0.
- The `BinderAwareChannelResolver` is deprecated in favor if providing `spring.cloud.stream.sendto.destination` property.
This is primarily for function-based programming model. For StreamListener it would still be required and thus will stay until we deprecate and eventually discontinue StreamListener
and annotation-based programming model.

38
docs/src/main/asciidoc/spring-cloud-stream.adoc
View File

@@ -1359,44 +1359,6 @@ Aside from static destinations, Spring Cloud Stream lets applications send messa
This is useful, for example, when the target destination needs to be determined at runtime.
Applications can do so in one of two ways.
===== BinderAwareChannelResolver
The `BinderAwareChannelResolver` is a special bean registered automatically by the framework.
You can autowire this bean into your application and use it to resolve output destination at runtime
The 'spring.cloud.stream.dynamicDestinations' property can be used for restricting the dynamic destination names to a known set (that is, intentionally allowed values).
If this property is not set, any destination can be bound dynamically.
The following example demonstrates one of the common scenarios where REST controller uses a path variable to determine target destination:
[source,java]
----
@SpringBootApplication
@Controller
public class SourceWithDynamicDestination {
@Autowired
private BinderAwareChannelResolver resolver;
@RequestMapping(value="/{target}")
@ResponseStatus(HttpStatus.ACCEPTED)
public void send(@RequestBody String body, @PathVariable("target") String target){
resolver.resolveDestination(target).send(new GenericMessage<String>(body));
}
}
----
Now consider what happens when we start the application on the default port (8080) and make the following requests with CURL:
----
curl -H "Content-Type: application/json" -X POST -d "customer-1" http://localhost:8080/customers
curl -H "Content-Type: application/json" -X POST -d "order-1" http://localhost:8080/orders
----
The destinations, 'customers' and 'orders', are created in the broker (in the exchange for Rabbit or in the topic for Kafka)
with names of 'customers' and 'orders', and the data is published to the appropriate destinations.
===== spring.cloud.stream.sendto.destination
You can also delegate to the framework to dynamically resolve the output destination by specifying `spring.cloud.stream.sendto.destination` header