Open boal opened 1 month ago
👋 Thanks for reporting! The maintainers have been notified and will get back to you.
@boal We would be very happy to receive a code contribution if you have a need for this feature
In my opinion one integration starter should not behave any differently than all the others. The behaviour with the automatic connection setup is probably caused by the digiwf-message lib. A cleaner way might be to move the message-starter from the s3-core to the s3-starter and build a second s3-starter just for REST.
Is your feature request related to a problem? Please describe. The digiwf digiwf-s3-integration-starter is listening as default via spring-cloud-stream to a message broker like kafka. With this feature it is possible to get a presigned-url over a message bus.
On the other hand, the
digiwf-s3-integration-starter
supports the creation of presigned urls via REST. If an application does not need the feature to connect to a message bus, the starter tries to connect to the bus anyway.To solve this problem, the
digiwf-s3-integration-starter
should have a property to disable the default behaviour of listening to the message bus. As a result, an application can use the digiwf-s3-integration-starter without a message bus.Describe the solution you'd like
Create a property to disable the default behaviour of listening to a message bus via spring-cloud-stream.
Describe alternatives you've considered
The exclusion of the spring-cloud-stream config classes has to be done by the application itself which is using the
digiwf-s3-integration-starter
. If this exclusion done by the user of thedigiwf-s3-integration-starter
itself is the prevered solution, the necessary procedure should be documented.A hardcoded solution to disable the default behaviour with exclusion of specific auto-configuration classes on start up can be found down below.
An alternative to the hard coded solution is to exclude the classes via the following spring property:
Acceptance Criteria
Additional context
n/a