QNameProvider
Related Docs:
trait QNameProvider
| package core
Simple QName provider using an immutable cache.
Simple QName provider using an immutable cache. It can be long-lived.
Simple caching QName provider.
Simple caching QName provider. The underlying cache is based on a normal Map implementation, so the cache can only grow. Therefore this QName provider is not meant to be a "global" cache with application scope, but it should be rather short-lived.
Thread-local QNameProvider.
Thread-local QNameProvider. This class exists because there is precisely one globally used QNameProvider, and by using this thread-local QNameProvider it is possible to make the global QNameProvider configurable per thread again. Also note that the QNameProviders bound to a thread are local to that thread, so they do not suffer from any thread-safety issues (unless a non-thread-safe QName provider instance is shared).
Note that each ThreadLocalQNameProvider instance (!) has its own thread-local QName provider. Typically it makes no sense to have more than one ThreadLocalQNameProvider instance in one application. In a Spring application, for example, a single instance of a ThreadLocalQNameProvider can be configured.
Trivial, non-caching, QName provider.
"Updatable" QName provider.
The implicit global QNameProvider is by default a "trivial" QNameProvider, but can be updated.
The implicit global QNameProvider is by default a "trivial" QNameProvider, but can be updated.
Being a val holding an UpdatableQNameProvider, instead of a var holding any QNameProvider, the identifier
QNameProvider.globalQNameProvider 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).