A)
A1) If a *ConfigSource *supports some kind of programmatic mutability,
when the changes are committed.
A2) If its underlying sources (I) or config sources (II) are changed:
I is an implementation detail of the *ConfgSource*
II by listening on changes of its child *ConfigSource*s
B)
I would propose an observer patterns, managing observers using Weak refs.
Payload something like a *ConfigChangeSet*, containing
- a reference to the config source (or the config source name ->
namespaces !)
- a set of changes, e.g. PropertyChangeEvents, where *propertyName =
property key*
WDYT...?
Mark Struberg <[email protected]> schrieb am Sun Dec 28 2014 at 14:54:36:
> Agree, there are many options on the table. And we have to think through
> all of them before we start implementing something.
>
>
> Imo it boils down to 2 different areas:
> A.) How do ConfigSources know when they need to reload
> B.) How to 'notify' the 'user code'
>
> LieGrue,
> strub
>
>
>
>
> > On Sunday, 28 December 2014, 13:59, John D. Ament <
> [email protected]> wrote:
> > > I think trying to add threads and polling would be a bad idea for now
> (too
> > heavy for a first pass). I think an initial pass can be as simple as
> > provide an API that reloads any configuration data under a specific
> > source. Allow the app developer to control when they want to see
> > configuration data. It could be through an admin interface (in a webapp)
> > or an RMI/JMX method or a JMS message coming in..
> >
> > If we did have a timer/thread, I think instead of an event we use a
> > functional interface to represent the call back to make when new config
> is
> > ready, perhaps taking the ChangeSet as an argument. Perhaps the CDI
> > integration can have a default implementation of this that fires an
> event.
> >
> > There is going to be config data we want to reload at runtime though
> (max #
> > of user sessions) vs config data we don't want to reload quite yet
> (change
> > the HTTP listen port; oops just brought down the environment..)
> >
> > On Sun Dec 28 2014 at 7:44:15 AM Mark Struberg <[email protected]>
> wrote:
> >
> >> The Environment is a different story I think. As far as I've seen it is
> >> more like a mixture of DeltaSpikes ProjectStage and other
> > 'features' like
> >> dbvendor, tenant, etc.
> >>
> >> That will be another huge brainstorming...
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >> > On Sunday, 28 December 2014, 12:43, Romain Manni-Bucau <
> >> [email protected]> wrote:
> >> > > should be configurable for sure but we'll get this internal
> > config
> >> > issue anyway (Environment of Anatole i guess). I'd just start with
> >> > system props and acceptable defaults.
> >> >
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau
> >> > http://www.tomitribe.com
> >> > http://rmannibucau.wordpress.com
> >> > https://github.com/rmannibucau
> >> >
> >> >
> >> >
> >> > 2014-12-28 12:40 GMT+01:00 Mark Struberg <[email protected]>:
> >> >> That could work. But what schedule time do you use, etc.
> >> >>
> >> >> LieGrue,
> >> >> strub
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sunday, 28 December 2014, 12:21, Romain Manni-Bucau
> >> > <[email protected]> wrote:
> >> >>
> >> >>
> >> >>>
> >> >>>
> >> >>> I d start with a scheduled thread rebuilding a transient
> > config. Then
> >> it
> >> > does a diff against current one. If the diff is not empty it switches
> > the
> >> > current config and sends the event.
> >> >>> Le 28 déc. 2014 12:01, "Mark Struberg"
> >> > <[email protected]> a écrit :
> >> >>>
> >> >>> Yea, this is an obvious benefit.
> >> >>>>
> >> >>>> I'm just having troubles to imagine how this should
> > get
> >> > implemented the best. And where do we put the responsibility to
> detect
> >> such a
> >> > change. In each ConfigSource? In the Configuration itself?
> >> >>>>
> >> >>>> To start easy: Consider a ConfigSource for myapp.property.
> > How do
> >> > you detect a change in there?
> >> >>>>
> >> >>>>
> >> >>>> LieGrue,
> >> >>>> strub
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Sunday, 28 December 2014, 11:44, Romain Manni-Bucau
> >> > <[email protected]> wrote:
> >> >>>>>
> >> >>>>> Hi
> >> >>>>> Most elegant solution ks to change a complete config
> > diff and
> >> > not a diff by key to allow to rebuikd config if needed. Listener can
> > then
> >> > listener by key pattern the event - a bit like WithAnnotations.
> >> >>>>> Letting client requery the config is not permant
> > enough + will
> >> > lead to N scheduled threads instead of 1 + forces all clients to have
> >> their own
> >> > refresh listening logic.
> >> >>>>> Le 28 déc. 2014 11:00, "Mark Struberg"
> >> > <[email protected]> a écrit :
> >> >>>>>
> >> >>>>> Hi!
> >> >>>>>>
> >> >>>>>> Another feature discussion is around supporting
> > changing
> >> > configured values while the application is running.
> >> >>>>>> This is the push/pull discussion if you remember.
> >> >>>>>>
> >> >>>>>> Pull:
> >> >>>>>>
> >> >>>>>> In DeltaSpike this was not a first class citizen
> > so to say.
> >> > It was doable because ConfigResolver always evaluates all the
> >> ConfigSources and
> >> > does not cache any resolved values. Thus we defer the caching to each
> >> > ConfigResolver.
> >> >>>>>> Of course this only works if you always call
> >> > ConfigResolver#getPropertyValue("mykey") and not for
> > injected config
> >> > values or if you only resolve the configuration once at startup.
> >> >>>>>>
> >> >>>>>> Pro:
> >> >>>>>> + straight forward
> >> >>>>>> + easy to provide
> >> >>>>>> + client can define the refresh rate
> >> >>>>>> Con:
> >> >>>>>> - more code at client
> >> >>>>>>
> >> >>>>>> - somewhat slower if config values get
> > re-evaluated each
> >> > time
> >> >>>>>> - application needs to handle caching
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Push:
> >> >>>>>> Whenever a configured value gets changed we send
> > an
> >> > 'event' which can be observed by the clients. This could be
> > done e.g. in
> >> > a Swing style with registering ConfigListeners. Later in a CDI module
> > we
> >> could
> >> > also register a central ConfigListener which relays this to a CDI
> > Event.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Open Questions from my side: who does trigger this
> > event?
> >> > And when? Do the ConfigSources detect any change themselves? Or does
> > the
> >> admin
> >> > need to trigger a 'reload' via JMX or similar?
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> LieGrue,
> >> >>>>>> strub
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >
> >>
> >
>
