spring.cloud.azure.servicebus.producer.entity-type not working

[fredysierra]

spring.cloud.azure.servicebus.producer.entity-type not working

[fredysierra]

@saragluna we know that adding this entity-type property is not hard. Our problem is the scale of this. We have many different services on our platform, and our clients can define their own services. For us and them, this would be a huge inconvenience. For now, we are looking into options to hack this. (adding the property dynamically ). However, it would be really important for us to have a property that defines the entity-type by default.

[joshfree]

@saragluna could you please help route @fredysierra's issue

[Netyyyy]

Hi @fredysierra , thanks for reaching out, we will take a look

[Netyyyy]

Hi @fredysierra , sorry for the inconvenience, spring.cloud.azure.servicebus.producer.entity-type and spring.cloud.azure.servicebus.consumer.entity-type doesn't work for bindings, please use spring.cloud.stream.servicebus.bindings.<binding-name>.consumer.entity-type or spring.cloud.stream.servicebus.bindings.<binding-name>.producer.entity-type instead, see Spring Cloud Stream support for more info.

If you use ARM to connect, it's necessary to configure each consumer or producer clearly, it's by design for provision resources and here is a sample. Or you use other way such connection-string, only need to configure
entity-type for producer.

[github-actions]

Hi @fredysierra. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[fredysierra]

Hi @fredysierra , sorry for the inconvenience, spring.cloud.azure.servicebus.producer.entity-type and spring.cloud.azure.servicebus.consumer.entity-type doesn't work for bindings, please use spring.cloud.stream.servicebus.bindings.<binding-name>.consumer.entity-type or spring.cloud.stream.servicebus.bindings.<binding-name>.producer.entity-type instead, see Spring Cloud Stream support for more info.

If you use ARM to connect, it's necessary to configure each consumer or producer clearly, it's by design for provision resources and here is a sample. Or you use other way such connection-string, only need to configure entity-type for producer.

Thank you so much for your answer. Considering this is a breaking change, it is frustrating that it was introduced in a minor upgrade version. As I mentioned to you, specifying entity-type per binder is a big inconvenience as we have a large number of producers and consumers in our product and our clients can define their own.

[Netyyyy]

Hi @fredysierra , it's an enhancement because in the past, it won't check if the entity-type is null

azure-sdk-for-java/sdk/spring/spring-cloud-azure-stream-binder-servicebus/src/main/java/com/azure/spring/cloud/stream/binder/servicebus/provisioning/ServiceBusChannelResourceManagerProvisioner.java

Line 66 in ceef374

Assert.notNull(consumerProperties.getEntityType(), "The EntityType of the consumer can't be null.");

and add this code to make sure user can configure the entity-type correctly.
As for the second question, @saragluna should we add a new feature for configuring one entity-type and all consumers and producers can use it?

[saragluna]

Sorry for the inconvenience, @fredysierra. Could you help share your configuration file? Setting on the producer/consumer is actually an intuitive way.

[saragluna]

@fredysierra may I ask whether you are using the ServiceBus binder to provison your queue or topic?

[fredysierra]

yes @saragluna We do use the binder to provision those.

[saragluna]

@fredysierra we'll try to fix this.

[saragluna]

Will fix it by enabling the default value by setting "spring.cloud.stream.servicebus.default.producer|consumer.xxx", which will be picked up as the default value of "spring.cloud.stream.servicebus.bindings.<channel-name>.producer|consumer.xxx".

[Netyyyy]

Fixed in Spring Cloud Azure 5.11/4.17