Listen Task Builder - Chaining until() and foreach() after to() #1460

What is the question:

I'm working on issue #1437 regarding the gaps and a question came up:

When attempting to use the current DSL constructor pattern to set up until and foreach in a listen task, there is a structuring issue that prevents the methods from chaining correctly.

The problem lies in the way the listen constructor is structured in : here

untilStep and strategyStep are configured separately, but both are applied within the same lambda passed to to().

This creates an order problem: when you do:

l.to(to().any(...))
    .until("expressao")
    .forEach("event", f -> ...)

The forEach() and until() methods attempt to return self() (the ListenSpec), but these methods would need to know which ListenTaskBuilder is being used to configure the foreach loop and the timeout, which are located in ListenTaskConfiguration, not ListenTo.

The to() function configures the ListenTo (the consumption strategy). However, foreach, timeout, and until are settings of the ListenTaskConfiguration, not the ListenTo.

My Test Failed

When we tried to use it like this:

listen("callDoctor", l -> {

l.to(to().any(...));

l.until("( . | length ) > 0"); // <-- until() does not exist in AbstractListenTaskBuilder

l.forEach("event", f -> ...); // <-- forEach() exists but needs the correct signature
})

The until(String) method does not exist in AbstractListenTaskBuilder - it only exists in ListenSpec (which is what you receive as a parameter from listen()). And even then, the until configured in ListenSpec is applied to AnyEventConsumptionStrategy, not to ListenTaskConfiguration.

I'd like to know the best solution for this from you guys. I can also do this in issue #1437, I just need guidance.

Because I've already done the part about the data gap and timeout, and the foreach loop.

Proposal(s):

Thinking about it quickly, I see 2 or 3 options:

1 - Add methods directly to AbstractListenTaskBuilder.
2 - Separate the to() configuration from the ListenTaskConfiguration configuration.
3 - Use nested consumer

Since this is a decision that affects the API design, I will wait for your response before doing anything....

Alternative(s):

No response

Additional info:

No response

Community Notes

• Please vote by adding a 👍 reaction to the feature to help us prioritize.
• If you are interested to work on this feature, please leave a comment.