Simple EName provider using an immutable cache.
Simple EName provider using an immutable cache. It can be long-lived.
Simple caching EName provider.
Simple caching EName provider. The underlying cache is based on a normal Map implementation, so the cache can only grow. Therefore this EName provider is not meant to be a "global" cache with application scope, but it should be rather short-lived.
Thread-local ENameProvider.
Thread-local ENameProvider. This class exists because there is precisely one globally used ENameProvider, and by using this thread-local ENameProvider it is possible to make the global ENameProvider configurable per thread again. Also note that the ENameProviders bound to a thread are local to that thread, so they do not suffer from any thread-safety issues (unless a non-thread-safe EName provider instance is shared).
Note that each ThreadLocalENameProvider instance (!) has its own thread-local EName provider. Typically it makes no sense to have more than one ThreadLocalENameProvider instance in one application. In a Spring application, for example, a single instance of a ThreadLocalENameProvider can be configured.
Trivial, non-caching, EName provider.
"Updatable" EName provider.
The implicit global ENameProvider is by default a "trivial" ENameProvider, but can be updated.
The implicit global ENameProvider is by default a "trivial" ENameProvider, but can be updated.
Being a val holding an UpdatableENameProvider, instead of a var holding any ENameProvider, the identifier
ENameProvider.globalENameProvider
is stable, and therefore its members can be imported.
Be careful: this global instance should be updated only during the "startup phase" of the application. Also be careful to choose an instance that is thread-safe and designed for a "long life" (unlike caching providers that can only grow a lot).