Remove DefaultMessage

[bitzl]

Problem

Flusswerk encourages implementation of custom messages that fit the respective applications. For a quick start, a DefaultMessage class is provided that has an String id and da Map<String, String> data.

This approach has several drawbacks:

Overuse of DefaultMessage in applications

There have are many applications where Developers use the HashMap<String, String> of DefaultMessage instead of a custom implementation, not only losing type safety and type information, but also revert to frequent String parsing and String comparison.

A custom message implementation also has a simpler JSON structure which greatly improves debugging and testing .

Mistaken use inside the Framework

The existence of DefaultMessage can be misleading on the Framework development itself, as to the confusing error handling implementation when receiving a message fails where a DefaultMessage is constructed, mimicking a broken message of arbitrary type:

flusswerk/engine/src/main/java/de/digitalcollections/flusswerk/engine/messagebroker/RabbitClient.java

Lines 117 to 122 in 5b08998

	} catch (Exception e) {
	Message invalidMessage = new DefaultMessage();
	invalidMessage.getEnvelope().setBody(body);
	invalidMessage.getEnvelope().setDeliveryTag(response.getEnvelope().getDeliveryTag());
	invalidMessage.getEnvelope().setSource(queueName);
	throw new InvalidMessageException(invalidMessage, e.getMessage());

Solution

Remove DefaultMessage and require a custom message implementation. Almost all usage is only in examples and tests where a suitable implementation can be provided. For easy implementation of custom messages, the abstract FlusswerkMessage can be used (also TraceableMessage, see #147).

[bitzl]

Resolved by #165