-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-3432: Add MQTT v5 channel adapters #3639
Conversation
Fixes spring-projects#3432 * Add `optional` dependency for `org.eclipse.paho:org.eclipse.paho.mqttv5.client` * Add `MqttProtocolErrorEvent` and emit it from the `mqttErrorOccurred()` callback of the MQTT v5 client * Add `MqttHeaderMapper` since MQTT v5 has introduced user properties pair to transfer over the protocol * Add `Mqttv5PahoMessageHandler` as one more extension of the `AbstractMqttMessageHandler` * Add more convenient `MqttHeaders` constants for easier headers mapping configuration * Ensure via `Mqttv5BackToBackTests` that MQTT v5 is supported by the provided components * Change `pr-build-workflow.yml` to use `eclipse-mosquitto` container for testing all the MQTT interactions * Change `cyrilix/rabbitmq-mqtt` service to the `rabbitmq:management` since RabbitMQ does not support MQTT v5
If this is OK, I'll go ahead with Doc. NOTE: RabbitMQ does not support MQTT v5, so I had to go with Mosquitto for both protocols testing. Thanks |
* Add `Mqttv5PahoMessageDrivenChannelAdapter.persistence` property
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; you could use TestContainers with mosquitto for the tests
https://stackoverflow.com/questions/51383126/mqtt-client-testing-with-junit/51384651
...va/org/springframework/integration/mqtt/inbound/AbstractMqttMessageDrivenChannelAdapter.java
Show resolved
Hide resolved
/** | ||
* The {@link AbstractMqttMessageDrivenChannelAdapter} implementation for MQTT v5. | ||
* | ||
* The {@link MqttProperties} are mapped via provided {@link HeaderMapper}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* The {@link MqttProperties} are mapped via provided {@link HeaderMapper}; | |
* The {@link MqttProperties} are mapped via the provided {@link HeaderMapper}; |
import org.springframework.messaging.converter.AbstractMessageConverter; | ||
import org.springframework.messaging.converter.SmartMessageConverter; | ||
import org.springframework.test.annotation.DirtiesContext; | ||
import org.springframework.test.context.junit4.SpringRunner; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JUnit4 for a new test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right., because our BrokerRunning
is JUnit 4 TestWatcher.
I don't want to introduce TestContainers into the project yet...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but this won't work on CI because it will fail (RabbitMQ plugin detected).
* Add `MosquittoContainerTest` for TestContainers support with Mosquitto image
If this is OK, I can go ahead and change all the MQTT tests to use that NOTE: to reuse container you should add |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say, yes, go ahead with the other tests, and deprecate BrokerRunning
.
|
||
@Container | ||
GenericContainer<?> MOSQUITTO_CONTAINER = | ||
new GenericContainer<>("eclipse-mosquitto:2.0.12") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not latest
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest
is somehow points to 2.0.7
on Docker Hub, which does not come with the /mosquitto-no-auth.conf
config and does not expose a listener to external world for connection.
It allows only loopback connections from the same host. Kinda black box inside the same container.
That's why I was so struggle to find how to use this container in our tests: eclipse-mosquitto/mosquitto#2119.
As you see the fix has made it only starting 2.0.8
and we cannot use ENV vars smoothly either. So, only the custom command .withCommand("mosquitto -c /mosquitto-no-auth.conf")
gave me a happy pass.
Actually, deprecation is not needed; it can be removed - it's not a public API. |
Co-authored-by: Gary Russell <[email protected]>
Let's merge this first, then I'll revise the rest of test in the separate commit not bothering you with review! Anyway let me know if all of this works well for you locally, before we merge and "break" other tests! |
Fixes #3432
optional
dependency fororg.eclipse.paho:org.eclipse.paho.mqttv5.client
MqttProtocolErrorEvent
and emit it from themqttErrorOccurred()
callback of the MQTT v5 clientMqttHeaderMapper
since MQTT v5 has introduced user properties pair to transfer over the protocolMqttv5PahoMessageHandler
as one more extension of theAbstractMqttMessageHandler
MqttHeaders
constants for easier headers mapping configurationMqttv5BackToBackTests
that MQTT v5 is supported by the provided componentspr-build-workflow.yml
to useeclipse-mosquitto
container for testing all the MQTT interactionscyrilix/rabbitmq-mqtt
service to therabbitmq:management
since RabbitMQ does not support MQTT v5