-
Notifications
You must be signed in to change notification settings - Fork 641
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
[Feature] Add HTTP Sink Connector #4824
Comments
I've used OkHttpClient to build an HTTP Sink Connector. I have some questions regarding message acknowledgment: Do you have any recommendations on this? ps: The |
I think an HTTP 200 response is enough to represent that the receiver processed the message correctly. EventMesh is planning in the future to have statistics on the delivery status of events, when it will be necessary to show the results of Webhook deliveries, including what is returned on the sink side. You may leave an extensible design with comments. Could you please use vertx which has been used in the HTTP Source Connector? Using the same third-party library improves code reusability and later extensibility, and avoids the problem that the Source Connector may produce faster than the Sink Connector can consume. |
OK, I will make the modifications based on your suggestions. |
I have a dependency issue to resolve in the My current approach is:
This is because the latest version of |
This is the current version in master branch: eventmesh/eventmesh-connectors/eventmesh-connector-http/build.gradle Lines 21 to 22 in fe2bd7c
For the same artifact, Gradle automatically uses the latest version in the dependency tree. If the old version is completely unupgradeable (which is important because upgrading a version is almost always better than downgrading), you can exclude transitive dependencies from conflicting artifacts. When upgrading, read the release note to avoid unintentionally breaking the functionality of the original code. My understanding of the situation you described is this:
@Fungx May I ask that what do you think of @cnzakii 's dependency conflict? |
Upon further investigation, I've determined that the dependency issue is unrelated to Therefore, we have two solutions:
|
Please do both. I've read the release notes of https://github.com/cloudevents/sdk-java, and it seems that there's no breaking change related to vertx between 2.3.0 and 3.0.0. According to https://vertx.io/docs/vertx-web-client/java/#_using_the_web_client, developers should declare their dependencies explicitly. I think the latest version won't have compatibility issues either. |
@Pil0tXia PTAL |
* feat: Add HTTP Sink Connector * refactor: Replace okHttpClient with vertx.WebClient * fix: Resolving dependency conflicts * test: Add HttpSinkConnectorTest * fix: Add License * fix: Solving dependency issues * fix: License Check * feat: Add HTTPS/SSL support * fix: Optimize logging * feat: Add webhook functionality * fix: Fix some bugs * test: add callback test * refactor: Add webhook Support * fix: Optimization tests and configuration additions * fix: code style * feat: rebuild WebhookHttpSinkHandler and add RetryHttpSinkHandler * fix: fix ci * refactor: Use failsafe alternative resilience4j and optimize webhook functionality * fix: fix License Check * fix: update something * fix: fix ci * fix: update something * fix: Optimized naming * fix: fix ci * fix: fix style check error * test: update HttpSinkConnectorTest
Search before asking
Feature Request
Send CloudEvents to a specific URL of a HTTP server (like a SpringBoot application endpoint or more).
Needs to support Webhook payload delivary with a general protocol.
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: