In the spirit of sharing and trying to move forward I started a branch on
my github fork:
https://github.com/rmannibucau/deltaspike/tree/fb/config-rework
For now it includes 1 ("easy") and 5 (pre 2 storage but will be part of the
refactoring "2" normally since we'll not break this API).
About 5 there is the question of the detection. By type is enough
technically but wonder if we should introduce @Source and @Filter just as
markers to ensure we don't also detect SPI sources and filters which are
likely CDI beans in a lot of apps.
Feedback welcomed ^^ :).
Once done, next step will be to add 3 then try to do 2. If all is good we
can work on the jira tickets.
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>
2016-11-06 21:40 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
> +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 <johndam...@apache.org>
> wrote:
> > > Some thoughts in line.
> >
> > On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > 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>
> >>
> >
>
