DomXmlMessageValidator accepts any payload for an empty control message

[bjoerndev]

In a complex special case we get an unexpected behavior of citrus XML comparison. I debugged into citrus and came to a line where I'm not sure if this is ok:

In DomXmlMessageValidator.validateMessageContent (at the moment line 342) [1] there is a
} else if (!StringUtils.hasText(controlMessagePayload)) { return; }
which causes that in case of an empty control message any payload gets accepted because the comparison ends without exception. I would expect throwing an exception or having an assert instead of the return.

Thank you for your great work and for checking this line.

[1]

citrus/modules/citrus-core/src/main/java/com/consol/citrus/validation/xml/DomXmlMessageValidator.java

Line 342 in 551834d

return;

[christophd]

Empty control message is an indicator that you are not interested in validating the message payload at all. This skips the payload message validation. This is a convention decision we made ages ago. I am not 100% happy with this either but it is the convention.

In case you need to really validate for an empty message payload you should use one of the validation matchers as expected payload e.g. @empty()@

[svettwer]

Hi @bjoerndev!

Did @christophd work for you or do you have any further questions?

BR,
Sven

[bjoerndev]

Hi @svettwer ,

thanks for looking at this.
For me there are no open tasks or questions: We have our own class derived from the original citrus validator where we put some special extensions. There I added that this case isn't allowed, and everything is fine for us now.
But general for Citrus I think this could be an unexpected and therefore dangerous behavior. So if there is time, I suggest changing this, or to add an explicit option to configure this.

Greetings, Björn

[svettwer]

Hi @bjoerndev,

yeah you're right. One should rethink this convention. Unfortunately this convention is not easy to change and there is actually no concrete requirement. Therefore we won't change this short term. Nevertheless, we'll keep this in mind in case that we've time for some major refactoring tasks.

BR,
Sven