Closed LeovR closed 4 days ago
Name | Link |
---|---|
Latest commit | 5d6eb3f59a56a1002d959a88a8e278950cc995f0 |
Latest deploy log | https://app.netlify.com/sites/springwolf-ui/deploys/673b68f61724d1000865b2d8 |
Deploy Preview | https://deploy-preview-1077--springwolf-ui.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
I haven't yet used the BiFunction
myself. Thus, I only added the BiConsumer
, since I'm familiar with that.
I think I should be possible in the same manner.
I also tested the refactoring with the FunctionCatalog
here.
But this is kind of a bigger refactoring and does not play well with the configured base-packages.
The change looks good to me, even when headers are not supported yet, it is a step in the right direction. Agreed, BiFunction can be a future improvement
Have a look at the publishing functionality, if there is no cloudstream way available, then lets leave it (+ useFqn) unchanged.
@timonback one could use the StreamBridge
for publishing in the cloud stream context.
See e. g. here
But I'm not completely sure whether this works because the other direction is required.
I also tested the refactoring with the FunctionCatalog here.
I like the change, it seems to be cloud-stream way. Feel free to go ahead - in a seperate PR.
Regarding the base-package: I think it is fair to assume that the Function must be declared in a specific package (which I hope can be inferred through the type). (Assuming: The information where the Function is defined as a bean is lost)
(Is a dependency required? I am not able to autowire it in the cloudstream-example.)
This addresses #1071 but only adds the
BiConsumer
.