Yes but still not clear for me why in particular when i see new needed features Le 26 févr. 2015 20:21, "Mark Struberg" <[email protected]> a écrit :
> Yes but the builder originally was intentionally left out at all… > > LieGrue, > strub > > > Am 26.02.2015 um 11:58 schrieb Anatole Tresch <[email protected]>: > > > > Basically only an interface for the ConfigurationContextBuilder. Nothing > more... > > > > - > > Anatole Tresch > > Glärnischweg 10 > > 8620 Wetzikon > > Tel +41 (43) 317 05 30 > > - > > Send from Mobile > > > >> Am 26.02.2015 um 11:07 schrieb Mark Struberg <[email protected]>: > >> > >> I smell some kind of overcomplicating things? > >> > >> How many classes would that add to our API? > >> And what is the benefit? > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 24.02.2015 um 14:19 schrieb Anatole Tresch <[email protected]>: > >>> > >>> Yes, makes sense, so I would refine my proposal to: > >>> > >>> - Create a ConfigurationContextBuilder. > >>> - We could hereby access a new ConfigurationContextBuilder from the > >>> ConfigurationProvider. > >>> - Extend the ConfigurationProvider with the > switch(ConfigurationContext) > >>> method. > >>> > >>> > >>> > >>> 2015-02-24 14:11 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >>> > >>>> Hmm > >>>> > >>>> Personally I'd prefer a builder (+ a clear lifecycle of the app build > >>>> phase) and a switch(ConfigContext) method to mutate it at runtime > >>>> build behing handled by the builder. switch would just be responsible > >>>> to 1) check the new config if needed, 2) fire the event(s) of the > >>>> update 3) do the real mutation > >>>> > >>>> said otherwise builder extracts the config of the config in its own > >>>> part and decorelate it from runtime > >>>> > >>>> wdyt? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau > >>>> http://www.tomitribe.com > >>>> http://rmannibucau.wordpress.com > >>>> https://github.com/rmannibucau > >>>> > >>>> > >>>> 2015-02-24 14:01 GMT+01:00 Anatole Tresch <[email protected]>: > >>>>> See inline... > >>>>> > >>>>> 2015-02-24 13:39 GMT+01:00 Romain Manni-Bucau <[email protected] > >: > >>>>> > >>>>>> Ok so ConfigurationContextUpdates is "part of the SPI" thanks to > >>>>>> ConfigurationContext itself, am I right? > >>>>> Yep. Also adding property sources already was there... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> That said seeing it I really think we should just use a builder > where > >>>>>> custom extensions (ServiceLoader in SE, events in CDI, getBeanOfType > >>>>>> in Spring) can add/remove components during "build" phase. > >>>>> > >>>>> The problem is that configuration changes during runtime exactly > change > >>>>> these things. E.g. > >>>>> > >>>>> - 1) > >>>>> a file could be removed -> the according propertysource > >>>>> ( > >>>>> s > >>>>> ) > >>>>> must be removed. > >>>>> - 2) a file could be added -> additional property source(s) must be > >>>>> registered. > >>>>> > >>>>> - 3) a file was updated -> coud simply be an update of the > >>>>> propertysource, but it could also mean that the ordinal has been > >>>> changed, > >>>>> so the whole chain must be reordered. In case a file produces entries > >>>> with > >>>>> different ordinals, multiple propertysources may be affected, > mappping > >>>>> logically to 1 and 2 again. > >>>>> > >>>>> So if we agree (and many people want that) that configuration can > change > >>>>> during runtime, we must allow this. > >>>>> If we want to prevent that we can simply never return a > >>>>> ConfigurationContextUpdate instance, everything will stay read-only. > >>>>> Breaking things basically is still a question of adding good default > >>>>> entries. Of course, if someone also removes the defaults, things may > get > >>>>> out of order, but I assume this is not a common case... > >>>>> > >>>>> Doing everything with a bulder is possible. We would then add > according > >>>>> methods > >>>>> > >>>>> ConfigurationContextBuilder getBuilder(); > >>>>> void apply(ConfigurationContext context); > >>>>> > >>>>> to the ConfigurationContext. WDYT? > >>>>> > >>>>> > >>>>> > >>>>>> Why I worry about it is this kind of thing: > >>>>>> > >>>>>> 1) start a context > >>>>>> 2) start to use the config > >>>>>> 3) wow this is awesome > >>>>>> 4) a part of the app modify it > >>>>>> 5) oops 2 and 3 are broken > >>>>>> > >>>>>> builder creating immutable objects sounds far better to me (by > itself, > >>>>>> then you can still mutate sources/converters if that's what you want > >>>>>> but that's not what we provide) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Romain Manni-Bucau > >>>>>> @rmannibucau > >>>>>> http://www.tomitribe.com > >>>>>> http://rmannibucau.wordpress.com > >>>>>> https://github.com/rmannibucau > >>>>>> > >>>>>> > >>>>>> 2015-02-24 13:24 GMT+01:00 Anatole Tresch <[email protected]>: > >>>>>>> Hi Roamin > >>>>>>> > >>>>>>> not sure, if I get your concerns: > >>>>>>> > >>>>>>> - the ConfigurationContext already is part of the current SPI. > >>>>>>> > >>>>>>> - the only change is that I extracted the methods for changing the > >>>>>> context > >>>>>>> into a separate process step/artifact with a fluent API style to > have > >>>>>> more > >>>>>>> control on changes applied. And I added additional functions, so I > >>>> also > >>>>>> can > >>>>>>> remove PropertySources, and have similar mechanisms for filters and > >>>> the > >>>>>>> other aspects. From what I wanted to achieve, currently only > >>>>>> PropertySource > >>>>>>> management per se, would be enough. But for me it would look > somehow > >>>>>>> weired, if I can change PropertySources, but not the rest... > >>>>>>> > >>>>>>> Anatole > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2015-02-24 11:57 GMT+01:00 Romain Manni-Bucau < > [email protected] > >>>>> : > >>>>>>> > >>>>>>>> Hmm > >>>>>>>> > >>>>>>>> I have to admit I'm a bit lost, is the SPI useful then? Do we need > >>>>>>>> another spi? Maybe to start we shouldnt use any spi then move to > spi > >>>>>>>> once API is finished > >>>>>>>> > >>>>>>>> That said this update new class looks like a builder to get > context > >>>>>>>> immutable which sounds more common and easier to understand to me > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Romain Manni-Bucau > >>>>>>>> @rmannibucau > >>>>>>>> http://www.tomitribe.com > >>>>>>>> http://rmannibucau.wordpress.com > >>>>>>>> https://github.com/rmannibucau > >>>>>>>> > >>>>>>>> > >>>>>>>> 2015-02-24 10:30 GMT+01:00 Anatole Tresch <[email protected]>: > >>>>>>>>> Hi all > >>>>>>>>> > >>>>>>>>> I would like to propose a small but effective change in the > >>>>>>>>> ConfigurationContext SPI (the explanation why comes later in this > >>>>>> email). > >>>>>>>>> Currently > >>>>>>>>> it is defined as: > >>>>>>>>> > >>>>>>>>> *public interface *ConfigurationContext { > >>>>>>>>> > >>>>>>>>> *void *addPropertySources(PropertySource... > propertySourcesToAdd); > >>>>>>>>> List<PropertySource> getPropertySources(); > >>>>>>>>> <T> *void *addPropertyConverter(TypeLiteral<T> typeToConvert, > >>>>>>>>> PropertyConverter<T> propertyConverter); > >>>>>>>>> <T> List<PropertyConverter<T>> > getPropertyConverters(TypeLiteral<T> > >>>>>>>> type); > >>>>>>>>> List<PropertyFilter> getPropertyFilters(); > >>>>>>>>> PropertyValueCombinationPolicy > getPropertyValueCombinationPolicy(); > >>>>>>>>> > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> My proposal is add an additional ConfigurationContextUpdates > >>>>>> interface, > >>>>>>>>> that allows to apply multiple changes to a ConfigurationContext > and > >>>>>>>> finally > >>>>>>>>> apply the changes, once they are done. So the interface would be > >>>>>> changed > >>>>>>>> as > >>>>>>>>> follows: > >>>>>>>>> > >>>>>>>>> *public interface *ConfigurationContext { > >>>>>>>>> > >>>>>>>>> List<PropertySource> getPropertySources(); > >>>>>>>>> <T> List<PropertyConverter<T>> > getPropertyConverters(TypeLiteral<T> > >>>>>>>> type); > >>>>>>>>> List<PropertyFilter> getPropertyFilters(); > >>>>>>>>> PropertyValueCombinationPolicy > getPropertyValueCombinationPolicy(); > >>>>>>>>> > >>>>>>>>> // moved methods: > >>>>>>>>> *// void *addPropertySources(PropertySource... > >>>> propertySourcesToAdd); > >>>>>>>>> // <T> *void *addPropertyConverter(TypeLiteral<T> typeToConvert, > >>>>>>>>> // PropertyConverter<T> > >>>>>> propertyConverter); > >>>>>>>>> *ConfigurationContextUpdates startUpdate(); // new* > >>>>>>>>> > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> ConfigurationContextUpdates would be defined as follows: > >>>>>>>>> > >>>>>>>>> *public interface *ConfigurationContextUpdates { > >>>>>>>>> > >>>>>>>>> ConfigurationContext getContext(); > >>>>>>>>> > >>>>>>>>> *default *ConfigurationContextUpdates > >>>>>>>>> addPropertySources(PropertySource... propertySourcesToAdd); > >>>>>>>>> ConfigurationContextUpdates > >>>>>>>>> addPropertySources(Collection<PropertySource> > >>>> propertySourcesToAdd); > >>>>>>>>> *default *ConfigurationContextUpdates > >>>>>>>>> removePropertySources(PropertySource... propertySourcesToRemove); > >>>>>>>>> ConfigurationContextUpdates > >>>>>>>>> removePropertySources(Collection<PropertySource> > >>>>>>>> propertySourcesToRemove); > >>>>>>>>> * default *ConfigurationContextUpdates > >>>>>>>>> removePropertySources(Predicate<PropertySource> selector); > >>>>>>>>> > >>>>>>>>> *default *ConfigurationContextUpdates > >>>>>>>>> addPropertyFilters(PropertyFilter... filters); > >>>>>>>>> ConfigurationContextUpdates > >>>>>>>>> addPropertyFilters(Collection<PropertyFilter> filters); > >>>>>>>>> *default *ConfigurationContextUpdates > >>>>>>>>> removePropertyFilters(PropertyFilter... filters); > >>>>>>>>> *default *ConfigurationContextUpdates > >>>>>>>>> removePropertyFilters(Predicate<PropertyFilter> selector); > >>>>>>>>> ConfigurationContextUpdates > >>>>>>>>> removePropertyFilters(Collection<PropertyFilter> filters); > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> <T> ConfigurationContextUpdates > >>>>>> addPropertyConverter(TypeLiteral<T> > >>>>>>>>> typeToConvert, > >>>>>>>>> > >>>>>>>>> PropertyConverter<T> propertyConverter); > >>>>>>>>> *default *ConfigurationContextUpdates > >>>>>>>>> removePropertyConverters(PropertyConverter<?>... converters); > >>>>>>>>> ConfigurationContextUpdates > >>>>>>>>> removePropertyConverters(Collection<PropertyConverter<?>> > >>>> converters); > >>>>>>>>> > >>>>>>>>> ConfigurationContextUpdates > >>>>>>>>> setPropertyValueCombinationPolicy(PropertyValueCombinationPolicy > >>>>>> policy); > >>>>>>>>> > >>>>>>>>> /** > >>>>>>>>> * Apply all the changes to the underlying context. > >>>>>>>>> * @throws java.lang.IllegalStateException if the operation is > >>>>>> called > >>>>>>>>> multiple times, or another update was already > >>>>>>>>> * applied before. > >>>>>>>>> */ > >>>>>>>>> *void *apply(); > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> Now here are the reasons, why I think this makes sense: > >>>>>>>>> > >>>>>>>>> - it is much more easy to lock/synchronize the current state of > >>>> a > >>>>>>>>> ConfigurationContext, since only for the time where the apply() > >>>> is > >>>>>>>>> running special synchronization logi > >>>>>>>>> - a configuration context can not support being mutable at all > >>>> by > >>>>>>>> simply > >>>>>>>>> throwing a UnsupportedMethodException, when startUpdate() is > >>>>>> called. > >>>>>>>>> - Changing a ConfigurationContext, e.g. for testing can now be > >>>> as > >>>>>>>>> flexible as using CDIUnit for CDI. The regarding test support > >>>>>>>> flexibility > >>>>>>>>> is easy to achieve. > >>>>>>>>> - *But most of all (and that was the reason, why I started to > >>>>>> think on > >>>>>>>>> this enhancements), we can implement automatic configuration > >>>>>> updates, > >>>>>>>> e.g. > >>>>>>>>> based on new files added to a configuration directory or added > >>>> to a > >>>>>>>>> database table, by implementing the mechanism as part of an > >>>> "event" > >>>>>>>> module. > >>>>>>>>> The event listener can determine from the change event the > >>>> affected > >>>>>>>>> PropertySource, compare with the PropertySource already > >>>> registered > >>>>>> in > >>>>>>>> the > >>>>>>>>> context(s) and remove/add/update new PropertySources as needed > >>>> for > >>>>>> the > >>>>>>>>> affected contexts. *This module currently is in development, > >>>> and as > >>>>>>>> soon > >>>>>>>>> as we would agree on this proposal I can add (and test it > >>>> before), > >>>>>> so > >>>>>>>> we > >>>>>>>>> have an initial version for supporting configuration updates. > >>>>>>>>> > >>>>>>>>> WDYT? > >>>>>>>>> > >>>>>>>>> Anatole > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> *Anatole Tresch* > >>>>>>> Java Engineer & Architect, JSR Spec Lead > >>>>>>> Glärnischweg 10 > >>>>>>> CH - 8620 Wetzikon > >>>>>>> > >>>>>>> *Switzerland, Europe Zurich, GMT+1* > >>>>>>> *Twitter: @atsticks* > >>>>>>> *Blogs: **http://javaremarkables.blogspot.ch/ > >>>>>>> <http://javaremarkables.blogspot.ch/>* > >>>>>>> > >>>>>>> *Google: atsticksMobile +41-76 344 62 79* > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> *Anatole Tresch* > >>>>> Java Engineer & Architect, JSR Spec Lead > >>>>> Glärnischweg 10 > >>>>> CH - 8620 Wetzikon > >>>>> > >>>>> *Switzerland, Europe Zurich, GMT+1* > >>>>> *Twitter: @atsticks* > >>>>> *Blogs: **http://javaremarkables.blogspot.ch/ > >>>>> <http://javaremarkables.blogspot.ch/>* > >>>>> > >>>>> *Google: atsticksMobile +41-76 344 62 79* > >>> > >>> > >>> > >>> -- > >>> *Anatole Tresch* > >>> Java Engineer & Architect, JSR Spec Lead > >>> Glärnischweg 10 > >>> CH - 8620 Wetzikon > >>> > >>> *Switzerland, Europe Zurich, GMT+1* > >>> *Twitter: @atsticks* > >>> *Blogs: **http://javaremarkables.blogspot.ch/ > >>> <http://javaremarkables.blogspot.ch/>* > >>> > >>> *Google: atsticksMobile +41-76 344 62 79* > >> > >
