Anatole Tresch created TAMAYA-353:
-------------------------------------
Summary: Improve support for different classloaders
Key: TAMAYA-353
URL: https://issues.apache.org/jira/browse/TAMAYA-353
Project: Tamaya
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.3-incubating
Reporter: Anatole Tresch
Assignee: Anatole Tresch
Fix For: 0.4-incubating
As of now now all components are loaded using a _ServiceContext_ abstraction.
This has shown to be useful because it gives you an abstraction very useful in
OSGI (works different) and testing (allows mocking). In the upcoming standard
as well as in Microprofile different configurations that use different
classloaders are suported explicitly, whereas in Tamaya this id done implicitly
(if at all) using the _ServiceContext_. This improvement proposes the following:
* Add the target _ClassLoader_ to the _ServiceContext_ (SPI extension)
* Accessing a _ServiceContext_ from the _ServiceContextManager_ requires a
_ClassLoader_ (SPI change)
* The _ServiceContext_ is passed and used accordingly by subsequent components
(SPI/API extension, examples: _PropertyConverterManager, PropertyFilterManager,
ConfigurationContext_) and builders (_ConfigurationBuilder_,
_ConfigurationContextBuilder_).
Since this change partially breaks the SPI, we have to discuss, if we must do a
major version upgrade.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
