Allow configuring the order of built-in EntityCallbacks

[rfelgent]

Hi @mp911de ,

the @Order of the built-in EntityCallbacks (at the time of writing AuditingEntityCallback and ValidatingEntityCallback) is not distinctive, both have the same configuration

        @Override
	public int getOrder() {
		return 100;
	}

Furthermore, I would like to make the value referencable by exposing them as public constant, e.g.:

public static final int ORDER = xxx;

This change allows a clean code regarding ordering of the buit-in and app provided EntityCallbacks.

[mp911de]

Auditing and validation should be orthogonal aspects that ideally should not affect each other. We're using Order to avoid falling into the Ordered.LOWEST_PRECEDENCE basket.

This change allows a clean code regarding ordering of the buit-in and app provided EntityCallbacks.

I am not quite sure how this would really help as the value is a static one. I could imagine on the other side to introduce setOrder(…) to configure ordering. That is a common pattern in Spring Framework (e.g. UrlBasedViewResolver, ProxyProcessorSupport) providing quite some flexibility to change ordering.

[rfelgent]

Hi @mp911de ,

I am not sure, If I could make clear the concerns regarding similar @Order values.

How do you know the order of entity callback if they all have the same order ? I think, there is already some kind of dependencies between callbacks.
Example: The AuditingCallback might manipulate fields annotated with @NotNull (e.g. modifiedBy). Therefore, I would like to have a guaranteed order, that the ValidatingEntityCallback gets triggered as last.

[mp911de]

Isn't using @NotNull on a @LastModifiedBy like writing a unit test to verify the framework is working correctly? That being said, I'm not sure what type of issue you're trying to solve.

Apart from that, introducing setOrder(…) on our callback implementations, enabling your application to customize the order, is totally fine with us.

[rfelgent]

I will Provide a merge request