Some thoughts in line. On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau <[email protected]> wrote:
> 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 > How does this relate, if at all, to Mark's proposal for config on geronimo? > > Proposals (no particular order but numbered to let it be referenced): > 1. Add converter to @ConfigProperty (cdi lookup or fallback on > newInstance() probably) > +1 > 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) > +1000 I hate the static methods for users. > 3. add an interface/abstract class based configuration "à la owner" > (probably reusing @ConfigProperty) > I've been thinking about this as well. Sounds like a good fit for partial bean. > 4. extract config in its own module to let it be reused more widely without > bringing all ds core > I like the idea. But I think the real problem is defining what is core vs what is a module. To me, core should be a lightweight component. We've stuck some extra stuff in there that can be a pain sometimes. May be worth an entirely separate thread. > 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 > Well, this kind of works today. Using a property source provider, I was able to create a archaius config source and have it discovered pretty early on. > > 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? > Would you be able to get the ideas into JIRA as a few different tickets? > > 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> >
