Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Consider to support CloudEvents: HeaderMappers, Transformers, MessageConverters etc. #3103

Open
artembilan opened this issue Nov 4, 2019 · 6 comments · May be fixed by #3246
Open

Consider to support CloudEvents: HeaderMappers, Transformers, MessageConverters etc. #3103

artembilan opened this issue Nov 4, 2019 · 6 comments · May be fixed by #3246
Labels
type: enhancement
Milestone
Backlog

Comments

@artembilan
Copy link
Member

See more info about Java SDK: https://github.com/cloudevents/sdk-java
@artembilan artembilan added this to the Backlog milestone Nov 4, 2019
@artembilan
Copy link
Member Author

Also see relevant JIRA for complete story: https://jira.spring.io/browse/INT-948

@dturanski
Copy link
Contributor

I see a few open questions here:

  • There are a couple of possible mappings from CloudEvent to Message, e.g., attributes natural maps to message headers and data (plus extensions?) to payload. Or the CE could be the simply be the payload. In this case the Message headers are independent.
  • Converting from Message to CE raises related questions.
  • The sdk supports 3 spec versions. The official spec only includes v1. What is the status of CE versions and which ones should SI support?

@artembilan
Copy link
Member Author

I think we need to support both variants:

  1. Natural mapping of headers and data into a Message incoming CE.
  2. A transparent conversion into a CE from message.

On the producer side we indeed can support CE as a payload, but I wonder if all the channel adapters should be fixed for this. Or it would be better just to make end-users to place a CEtoMessageTransformer (or Converter) (or serializer since we are going to send byte[]) before sending CE into the target protocol.
Doesn't look like it worth to chase all the protocol binders since we simply can map a CE instance (or message headers + payload) to an expected CE network structure in one transformer/converter/serializer place.

I'm not familiar with spec versions, but let's implement first of all what is supported by Java SDK!

Thank you for feedback, @dturanski !

@dturanski
Copy link
Contributor

I'm not familiar with spec versions, but let's implement first of all what is supported by Java SDK! That's my point. The Java SDK implements 3 versions, e.g., io.cloudevents.v1.CloudEventImpl, io.cloudevents.v02.CloudEventImpl, io.cloudevents.v03.CloudEventImpl. The only documentation I can find on this is https://github.com/cloudevents/spec which only mentions v1.0 but if we depend on the SDK, all versions are available.

@artembilan
Copy link
Member Author

Oh! I see what you mean. So, if it is something new for us, we should rely on the latest version!
You should adapt from the old version by yourself. Or we can implement adapters on demand...

@dturanski
Copy link
Contributor

Re https://jira.spring.io/browse/INT-948. I'm not sure if CE really helps because the real payload is a member of CE T data. The consumer and producer still both need to be aware of the type. spring-tuple, basically a map with type conversion had a similar goals. In any case, I would not standardize on CE for all channel adapters, providing support is OK.

@artembilan artembilan mentioned this issue Jan 28, 2020
Closed
artembilan added a commit to artembilan/spring-integration that referenced this issue Apr 9, 2020
@artembilan
spring-projectsGH-3103: Introduce CloudEvents transformers
ceee505 
Fixes spring-projects#3103

* Add an `io.cloudevents:cloudevents-api` optional dependency
* Introduce a `HeaderMapper` and `Marshallers` in the `support.cloudevents`
to marshal `CloudEvent` instances
* Introduce a `ToCloudEventTransformer` to build a `CloudEvent` instance
from a `Message` and optional marshaling logic if necessary.
Such a transformer could be used as a general purpose CE protocol binder
before sending a result message into the target protocol channel adapter
@artembilan artembilan linked a pull request Apr 9, 2020 that will close this issue
Draft
artembilan added a commit to artembilan/spring-integration that referenced this issue Apr 16, 2020
@artembilan
spring-projectsGH-3103: Introduce CloudEvents transformers
962ba1a 
Fixes spring-projects#3103

* Add an `io.cloudevents:cloudevents-api` optional dependency
* Introduce a `HeaderMapper` and `Marshallers` in the `support.cloudevents`
to marshal `CloudEvent` instances
* Introduce a `ToCloudEventTransformer` to build a `CloudEvent` instance
from a `Message` and optional marshaling logic if necessary.
Such a transformer could be used as a general purpose CE protocol binder
before sending a result message into the target protocol channel adapter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: enhancement
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

[DO NOT MERGE YET] GH-3103: Introduce CloudEvents transformers artembilan/spring-integration
2 participants
@dturanski @artembilan