Add CloudEventHeadersBuilder DSL support - #10828
Conversation
| return IntegrationFlow | ||
| .from("inputChannel") | ||
| .enrichHeaders(CloudEvents.headers() | ||
| .idExpression("headers['orderId']") |
There was a problem hiding this comment.
May we use MapAccessor style in the doc as well, please?
There was a problem hiding this comment.
Was not addressed.
Or just comment here, please, why you have not changed it, but approved.
| * @param prefix the event prefix | ||
| * @return the builder | ||
| */ | ||
| public CloudEventHeadersBuilder prefix(String prefix) { |
There was a problem hiding this comment.
No. I still don't believe in this method.
Why to give a paradox of choice to user?
There is a ctor requesting such a prefix.
So, on any other mutators, please.
It also may cause the problem.
Let's imaging I have started with a default prefix!
Gave it a couple attributes, then decided to change the prefix.
But only the others after this method are going to be modified.
That is an inconsistency, which is possible, but probably with a generic enrichHeaders API, not with this builder for its own DSL-specific case.
| private String eventDataSchemaKey = CloudEventHeaders.EVENT_DATA_SCHEMA; | ||
|
|
||
| /** | ||
| * Create a new {@link CloudEventHeadersBuilder}. |
| */ | ||
| public CloudEventHeadersBuilder(String prefix) { | ||
| this.prefix = prefix; | ||
| updatePrefix(); |
There was a problem hiding this comment.
I think we don't need this extra method and do all the properties modification directly here.
I also still believe in some compiler optimization when we declare properties as final.
We probably won't need prefix after modified the rest of attributes here on the fly.
| * @return the {@link ToCloudEventTransformerSpec} instance | ||
| */ | ||
| public static ToCloudEventTransformerSpec toCloudEventTransformer(String... extensionPatterns) { | ||
| return new ToCloudEventTransformerSpec(extensionPatterns); | ||
| } | ||
|
|
||
| /** | ||
| * Create a {@link CloudEventHeadersBuilder}. |
|
|
||
| @Test | ||
| void testEnrichHeadersWithDirectValues(@Autowired @Qualifier("directFlow.input") MessageChannel inputChannel) { | ||
|
|
There was a problem hiding this comment.
So, we don't need this blank line then?
Just minor, of course, but I wonder if we try to pursue consistence and perfect code.
| IntegrationFlow functionFlow() { | ||
| return flow -> flow | ||
| .enrichHeaders(CloudEvents.headers() | ||
| .dataSchemaFunction(msg -> URI.create("https://example.com/schema/" + |
There was a problem hiding this comment.
I would prefer to put the whole lambda body on a new line, rather than break on string concatenation.
| return IntegrationFlow | ||
| .from("inputChannel") | ||
| .enrichHeaders(CloudEvents.headers() | ||
| .idExpression("headers['orderId']") |
There was a problem hiding this comment.
Was not addressed.
Or just comment here, please, why you have not changed it, but approved.
| == CloudEvent Headers Builder | ||
|
|
||
| Use the `CloudEventHeadersBuilder` to set CloudEvent headers using Spring Integration's DSL. | ||
| Access the builder through the `CloudEvents.headers()` factory method. |
There was a problem hiding this comment.
Not saying that it is critical.
I feel discomfort with these two sentences.
Both of them are kind of commands I have to do.
Even if they don't use word you, it is still implied.
And this doc gives me some instructions.
In my understanding it has to explain a behavior of the API, not commands what and how to use.
Makes sense?
Or do I exaggerate?
artembilan
left a comment
artembilan
left a comment
There was a problem hiding this comment.
This is good now.
Just one concern with rebasing and redundant now suppress annotations.
Thanks
| * @param time the event timestamp | ||
| * @return the builder | ||
| */ | ||
| @SuppressWarnings("NullAway") |
There was a problem hiding this comment.
Please, rebase to the latest main and remove these warnings since nullability is there already.
Thanks
Introduce `CloudEventHeadersBuilder` to allow setting CloudEvent headers via the Spring Integration DSL using direct values, SpEL expressions, or Java functions. Expose the builder through a `CloudEvents.headers()` factory method.
- Update `CloudEventHeadersBuilder` to properly support nullable values
by changing the type parameter from `Object` to `@Nullable Object`.
- Remove remove `NullAway` `@SuppressWarnings`
96d407d to
a101b30
Compare
2 participants
Introduce
CloudEventHeadersBuilderto allow setting CloudEvent headers via the Spring Integration DSL using direct values, SpEL expressions, or Java functions. Expose the builder through aCloudEvents.headers()factory method.