IdentifierResolver Configuration

Proposed Solution

Proposed method based on idea that only one IdentifierResolver bean is exists within the context, and the process of this bean election during context initialization is controlled by the set of configuration properties. Method implies convention to add configuration properties which controls resolver bean creation for each core resolver as well as custom resolvers.

Alternatives

Possible alternative of properties controlled creation process is conditional process based on criteria of bean existence, this method may introduce convention that defines and implies next initialization rule: if there is no other resolver beans within an application context, the core resolver bean is used._

But, this method would lead to error configuration, at firs in cases where some resolvers may be configured indirectly through third dependencies that would lead to configuration clash and unexpected and unpredictable behaviours when more then one resolver bean is exists.

Implementation

Implemented configuration module provides core identifier resolver which creation is enabled by default, but could be disabled by the org.ametiste.metrics.core.identifier-resolver.enabled property. So the core configuration variant must be usable for most of clients. Client configurations where other identifier resolver is required should disable core identifier resolver using provided property and enable desired identifier resolver.

Spring Autowire mechanism of dependencies selection which reject configuration process if more than one bean of a type is exists will prevent possible configuration clashes through third dependencies.

For example, if some client wants to use IdentifierTemplateResolver, client configuration must disable creation of core identifier and enable creation of template resolver through configuration properties

org.ametiste.metrics.core.identifier-resolver.enabled=false
org.ametiste.metrics.staff.identifier-resolver.enabled=true