+1 for moving the Config out into an own module. It's the best we can do for now. The JSR will likely take a bit to evolve and until then we can use what we have in DeltaSpike. Just a bit cleaned up.
LieGrue, strub PS: a single ticket is by far enough imo. > On Sunday, 6 November 2016, 21:28, John D. Ament <[email protected]> > wrote: > > 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> >> >
