[TAMAYA-353] Improve support for different classloaders

• Type: Improvement
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 0.3-incubating
• Fix Version/s: 0.4-incubating
• Component/s: API, Core
• Assignee: Anatole Tresch
• Reporter: Anatole Tresch
• Created: 27/Sep/18 12:54
• Updated: 18/Nov/18 21:51
• Resolved: 18/Nov/18 21:51

Description

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.