Re: Defining a clear context builder pattern
Am 18.10.2016 um 19:25 schrieb Werner Keil: > Unless it totally broke compatibility of those apps, projects and clients > that we spoke about earlier, I see no problem doing it on master/trunk > either. +1 it seems fine and reasonable to me - let's give it a try. Phil
Re: Defining a clear context builder pattern
No the default behaviour is the same. I even did not rewrite the tests much for the builder mentioned, but mainly extended them. Configuration API and default behaviour of loading configuration will be exactly the same. The only case is when application where using the builder for creating config manually, but this is IMO relatively unlikely, since the corresponding API part for creating a configuration based on a context was not yet accessible... 2016-10-18 19:25 GMT+02:00 Werner Keil : > Unless it totally broke compatibility of those apps, projects and clients > that we spoke about earlier, I see no problem doing it on master/trunk > either. > > > > > On Tue, Oct 18, 2016 at 7:22 PM, Anatole Tresch > wrote: > > > Currently not. It is not yet pushed, since I have first to reorganize my > > folders with the latest modules changes. > > And first of all I am interested in a content-wise feedback/questions. I > > dont care if we > > put it into branch A or B ... this does not mean I cannot push it into > some > > branch but this takes more time, > > around WE or so. And I thaught we can start with some basic discussions > > ahead... > > > > 2016-10-18 17:27 GMT+02:00 Werner Keil : > > > > > Would that be in a separate branch to start with? > > > > > > Werner > > > > > > > > > On Tue, Oct 18, 2016 at 4:42 PM, Anatole Tresch > > > wrote: > > > > > > > Hi all > > > > > > > > based on the work to see how easy some of the ideas of Dimitry (the > > > > designated Oracle spec lead for config) could be implemented I would > > like > > > > to propose some adaptions and changes: > > > > > > > >- I would basically resolve the current duplication of the builder > > > >pattern (in the builder module as well as in the core API). The > core > > > API > > > >itself is already based on an interface, which if done right IMO > > gives > > > > all > > > >the flexibility needed and also would make some of the more > implicit > > > >mechanism more explicit. > > > >- The main API changes required are on the > > > *ConfigurationContextBuilder* > > > >SPI interface: > > > > - this interface as of now already contains methods for adding > > and > > > > removing of property sources, filters and converters. Most of > the > > > > methods > > > > are implemented in two variants as of now: once taking a > > > Collection, > > > > once > > > > using an ellipse operator taking single items or arrays. > > > > Unfortunately some > > > > of the methods are not fully present in both variants, so I > > > > propoase to add > > > > the missing counterparts. This basically is not a functional > > > change, > > > > but > > > > makes the API more concise. > > > > - currently the implementation of the builder implicitly > applies > > > > sorting of property sources and filters using its internal > > sorting > > > > algorithm. This works well, but in case, where I dont want to > use > > > the > > > > ordinal pattern, e.g. because I have configured a different > > > > hierarchy in a > > > > XML meta-config file, this implicit sorting makes it hard to > > build > > > > up a > > > > property source chain in a transparent and clear way (using the > > > > builder). I > > > > would expect the builder to NOT perform any sorting implicitly. > > > > Instead > > > > sorting is controlled by calling the appropriate sort methods > > > hereby > > > > passing a *Comparator*. So I propose to add to methods > > > > *sortPropertySources(Comparator) > > > > *and *sortPropertyFilters(Comparator) *to the builder > interface. > > > > - Given that the *ConfigurationContextBuilder* actually manages > > an > > > > ordered list of property sources. In case I want to > > > increase/decrese > > > > the > > > > priority of a property source or make it the most/least > > significant > > > > one. > > > > Therefore I propose to add the methods *(incresePriority( > > > > PropertySource), > > > > decresePriority(PropertySource), > lowestPriority(PropertySource), > > > > highestPriority(PropertySource)*. One use case is creating a > > > builder > > > > from an existing *ConfigurationContext* and change the priority > > of > > > > some of its property sources. Also these methods do strictly > > > > operate on the > > > > ordering only, they will not change implicitly any ordinals. > > > > - For implementing module it has shown that access tot he > current > > > > property sources, filters and converters of a builder is > useful. > > > > Creating a > > > > context and accessing later does not work, since the builder > > > supports > > > > building an instance only once. So I propose to add the methods > > > > *getPropertySources(),getPropertyFilters(), > > > > getPropertyConverter()*. > > > >- Finally given a *ConfigurationContext* built with the builder, I > > > wan
Re: Defining a clear context builder pattern
Unless it totally broke compatibility of those apps, projects and clients that we spoke about earlier, I see no problem doing it on master/trunk either. On Tue, Oct 18, 2016 at 7:22 PM, Anatole Tresch wrote: > Currently not. It is not yet pushed, since I have first to reorganize my > folders with the latest modules changes. > And first of all I am interested in a content-wise feedback/questions. I > dont care if we > put it into branch A or B ... this does not mean I cannot push it into some > branch but this takes more time, > around WE or so. And I thaught we can start with some basic discussions > ahead... > > 2016-10-18 17:27 GMT+02:00 Werner Keil : > > > Would that be in a separate branch to start with? > > > > Werner > > > > > > On Tue, Oct 18, 2016 at 4:42 PM, Anatole Tresch > > wrote: > > > > > Hi all > > > > > > based on the work to see how easy some of the ideas of Dimitry (the > > > designated Oracle spec lead for config) could be implemented I would > like > > > to propose some adaptions and changes: > > > > > >- I would basically resolve the current duplication of the builder > > >pattern (in the builder module as well as in the core API). The core > > API > > >itself is already based on an interface, which if done right IMO > gives > > > all > > >the flexibility needed and also would make some of the more implicit > > >mechanism more explicit. > > >- The main API changes required are on the > > *ConfigurationContextBuilder* > > >SPI interface: > > > - this interface as of now already contains methods for adding > and > > > removing of property sources, filters and converters. Most of the > > > methods > > > are implemented in two variants as of now: once taking a > > Collection, > > > once > > > using an ellipse operator taking single items or arrays. > > > Unfortunately some > > > of the methods are not fully present in both variants, so I > > > propoase to add > > > the missing counterparts. This basically is not a functional > > change, > > > but > > > makes the API more concise. > > > - currently the implementation of the builder implicitly applies > > > sorting of property sources and filters using its internal > sorting > > > algorithm. This works well, but in case, where I dont want to use > > the > > > ordinal pattern, e.g. because I have configured a different > > > hierarchy in a > > > XML meta-config file, this implicit sorting makes it hard to > build > > > up a > > > property source chain in a transparent and clear way (using the > > > builder). I > > > would expect the builder to NOT perform any sorting implicitly. > > > Instead > > > sorting is controlled by calling the appropriate sort methods > > hereby > > > passing a *Comparator*. So I propose to add to methods > > > *sortPropertySources(Comparator) > > > *and *sortPropertyFilters(Comparator) *to the builder interface. > > > - Given that the *ConfigurationContextBuilder* actually manages > an > > > ordered list of property sources. In case I want to > > increase/decrese > > > the > > > priority of a property source or make it the most/least > significant > > > one. > > > Therefore I propose to add the methods *(incresePriority( > > > PropertySource), > > > decresePriority(PropertySource), lowestPriority(PropertySource), > > > highestPriority(PropertySource)*. One use case is creating a > > builder > > > from an existing *ConfigurationContext* and change the priority > of > > > some of its property sources. Also these methods do strictly > > > operate on the > > > ordering only, they will not change implicitly any ordinals. > > > - For implementing module it has shown that access tot he current > > > property sources, filters and converters of a builder is useful. > > > Creating a > > > context and accessing later does not work, since the builder > > supports > > > building an instance only once. So I propose to add the methods > > > *getPropertySources(),getPropertyFilters(), > > > getPropertyConverter()*. > > >- Finally given a *ConfigurationContext* built with the builder, I > > want > > >to create a *Configuration* instance. The corresponding method > > > *createConfiguration(ConfigurationContext) > > >*is already defined on the *ConfigurationProviderSpi* interface. So > I > > >would like to add it as well on the *ConfigurationProvider*. > Obviously > > >building a configuration MUST resepct/ensure the precendece of > > property > > >sources as defined by its context (which by now, was not the case). > > > > > > With these changes we have a much better separation of concerns: > > > > > >- we have an ordered list of property sources. The ordering hereby > can > > >be ordinal based (used by default). > > >- But using the ConfigurationContextBuilder alternate strategi
Re: Defining a clear context builder pattern
Currently not. It is not yet pushed, since I have first to reorganize my folders with the latest modules changes. And first of all I am interested in a content-wise feedback/questions. I dont care if we put it into branch A or B ... this does not mean I cannot push it into some branch but this takes more time, around WE or so. And I thaught we can start with some basic discussions ahead... 2016-10-18 17:27 GMT+02:00 Werner Keil : > Would that be in a separate branch to start with? > > Werner > > > On Tue, Oct 18, 2016 at 4:42 PM, Anatole Tresch > wrote: > > > Hi all > > > > based on the work to see how easy some of the ideas of Dimitry (the > > designated Oracle spec lead for config) could be implemented I would like > > to propose some adaptions and changes: > > > >- I would basically resolve the current duplication of the builder > >pattern (in the builder module as well as in the core API). The core > API > >itself is already based on an interface, which if done right IMO gives > > all > >the flexibility needed and also would make some of the more implicit > >mechanism more explicit. > >- The main API changes required are on the > *ConfigurationContextBuilder* > >SPI interface: > > - this interface as of now already contains methods for adding and > > removing of property sources, filters and converters. Most of the > > methods > > are implemented in two variants as of now: once taking a > Collection, > > once > > using an ellipse operator taking single items or arrays. > > Unfortunately some > > of the methods are not fully present in both variants, so I > > propoase to add > > the missing counterparts. This basically is not a functional > change, > > but > > makes the API more concise. > > - currently the implementation of the builder implicitly applies > > sorting of property sources and filters using its internal sorting > > algorithm. This works well, but in case, where I dont want to use > the > > ordinal pattern, e.g. because I have configured a different > > hierarchy in a > > XML meta-config file, this implicit sorting makes it hard to build > > up a > > property source chain in a transparent and clear way (using the > > builder). I > > would expect the builder to NOT perform any sorting implicitly. > > Instead > > sorting is controlled by calling the appropriate sort methods > hereby > > passing a *Comparator*. So I propose to add to methods > > *sortPropertySources(Comparator) > > *and *sortPropertyFilters(Comparator) *to the builder interface. > > - Given that the *ConfigurationContextBuilder* actually manages an > > ordered list of property sources. In case I want to > increase/decrese > > the > > priority of a property source or make it the most/least significant > > one. > > Therefore I propose to add the methods *(incresePriority( > > PropertySource), > > decresePriority(PropertySource), lowestPriority(PropertySource), > > highestPriority(PropertySource)*. One use case is creating a > builder > > from an existing *ConfigurationContext* and change the priority of > > some of its property sources. Also these methods do strictly > > operate on the > > ordering only, they will not change implicitly any ordinals. > > - For implementing module it has shown that access tot he current > > property sources, filters and converters of a builder is useful. > > Creating a > > context and accessing later does not work, since the builder > supports > > building an instance only once. So I propose to add the methods > > *getPropertySources(),getPropertyFilters(), > > getPropertyConverter()*. > >- Finally given a *ConfigurationContext* built with the builder, I > want > >to create a *Configuration* instance. The corresponding method > > *createConfiguration(ConfigurationContext) > >*is already defined on the *ConfigurationProviderSpi* interface. So I > >would like to add it as well on the *ConfigurationProvider*. Obviously > >building a configuration MUST resepct/ensure the precendece of > property > >sources as defined by its context (which by now, was not the case). > > > > With these changes we have a much better separation of concerns: > > > >- we have an ordered list of property sources. The ordering hereby can > >be ordinal based (used by default). > >- But using the ConfigurationContextBuilder alternate strategies can > be > >easily defined by implementing a different Comparator being used or > >applying the ordering required using the methods offerend on the > > builder. > >- Using ordinals is the default way provided, but using modules we can > >easily provide alternate strategies as well. > >- This will quite probably also help with contextual aspects, once it > is > >more clear, what contextuality means regarding conf
Re: Defining a clear context builder pattern
Would that be in a separate branch to start with? Werner On Tue, Oct 18, 2016 at 4:42 PM, Anatole Tresch wrote: > Hi all > > based on the work to see how easy some of the ideas of Dimitry (the > designated Oracle spec lead for config) could be implemented I would like > to propose some adaptions and changes: > >- I would basically resolve the current duplication of the builder >pattern (in the builder module as well as in the core API). The core API >itself is already based on an interface, which if done right IMO gives > all >the flexibility needed and also would make some of the more implicit >mechanism more explicit. >- The main API changes required are on the *ConfigurationContextBuilder* >SPI interface: > - this interface as of now already contains methods for adding and > removing of property sources, filters and converters. Most of the > methods > are implemented in two variants as of now: once taking a Collection, > once > using an ellipse operator taking single items or arrays. > Unfortunately some > of the methods are not fully present in both variants, so I > propoase to add > the missing counterparts. This basically is not a functional change, > but > makes the API more concise. > - currently the implementation of the builder implicitly applies > sorting of property sources and filters using its internal sorting > algorithm. This works well, but in case, where I dont want to use the > ordinal pattern, e.g. because I have configured a different > hierarchy in a > XML meta-config file, this implicit sorting makes it hard to build > up a > property source chain in a transparent and clear way (using the > builder). I > would expect the builder to NOT perform any sorting implicitly. > Instead > sorting is controlled by calling the appropriate sort methods hereby > passing a *Comparator*. So I propose to add to methods > *sortPropertySources(Comparator) > *and *sortPropertyFilters(Comparator) *to the builder interface. > - Given that the *ConfigurationContextBuilder* actually manages an > ordered list of property sources. In case I want to increase/decrese > the > priority of a property source or make it the most/least significant > one. > Therefore I propose to add the methods *(incresePriority( > PropertySource), > decresePriority(PropertySource), lowestPriority(PropertySource), > highestPriority(PropertySource)*. One use case is creating a builder > from an existing *ConfigurationContext* and change the priority of > some of its property sources. Also these methods do strictly > operate on the > ordering only, they will not change implicitly any ordinals. > - For implementing module it has shown that access tot he current > property sources, filters and converters of a builder is useful. > Creating a > context and accessing later does not work, since the builder supports > building an instance only once. So I propose to add the methods > *getPropertySources(),getPropertyFilters(), > getPropertyConverter()*. >- Finally given a *ConfigurationContext* built with the builder, I want >to create a *Configuration* instance. The corresponding method > *createConfiguration(ConfigurationContext) >*is already defined on the *ConfigurationProviderSpi* interface. So I >would like to add it as well on the *ConfigurationProvider*. Obviously >building a configuration MUST resepct/ensure the precendece of property >sources as defined by its context (which by now, was not the case). > > With these changes we have a much better separation of concerns: > >- we have an ordered list of property sources. The ordering hereby can >be ordinal based (used by default). >- But using the ConfigurationContextBuilder alternate strategies can be >easily defined by implementing a different Comparator being used or >applying the ordering required using the methods offerend on the > builder. >- Using ordinals is the default way provided, but using modules we can >easily provide alternate strategies as well. >- This will quite probably also help with contextual aspects, once it is >more clear, what contextuality means regarding configuration and also > make >implementation of a company specific strategy much more easier. > > There is one disadvantage I dont want to omit: the changes in the > implementation are not fully behavioural compatible wuth code that already > is using the builder pattern. Since the method for creating a new > Configuration instance has not been exposed I expect the changes only > affect code within Tamaya itself (basically mostly some testing and code in > the core, but not much). > > ​Feedback is welcome. The changes described are actually implemented, > testing and are all working and have proven to work well. So if nobody > comp
