Hi guys sent it some times ago - ok, a long time ago now ;) - but will retry with few more details now.
Goal: I'd like to rework a bit our configuration Proposals (no particular order but numbered to let it be referenced): 1. Add converter to @ConfigProperty (cdi lookup or fallback on newInstance() probably) 2. remove the map storage we have and replace it by 2.a. a thread local during the boot ConfigResolver would use 2.b. a config bean for the runtime (BeanProvider or CDI.current() allow to get it easily) 3. add an interface/abstract class based configuration "à la owner" (probably reusing @ConfigProperty) 4. extract config in its own module to let it be reused more widely without bringing all ds core 5. support during bootstrap the detection of converters and sources (not only propertyfile ones) and add them in the runtime config added in 2.b 2. implies we don't use the config in extension constructor (which should be fine) and that we can cleanup the thread local after CDI startup (here we can have few options to enforce this cleanup like using AfterDeploymentValidation by default + probably either some container dependent solutions or at least a ServletContextListener#contextDestroyed for the case deployment fails) Excepted the usability (converter option, extraction in a dedicated module) the goal is to not do any concurrence to CDI lookup mecanism and stay 100% aligned on it. In term of usability the fact to be able to have a real CDI source DTO for runtime and reuse default ones (system properties, properties in classpath, etc..) for the extension itself (internal application configuration) is a huge gain IMHO. Wdyt? Any blocker? This would likely lead to a 1.8. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com>
