Sounds good for me. In the meantime looking back the discussions we have, I really like the ordinal way, for ordering the top level: as you side intuititve and easy. I also like to provide the builder styled part for supporting implementation of the top level for the ones defining their metamodels (as part of core, or even a module, not part of API), what i delivered by a top level source. With names (see other mail) we also would have some namespace concept to address things...
But, cool, we are now on the same page! Mark Struberg <[email protected]> schrieb am Sun Dec 28 2014 at 14:53:26: > "All problems in computer science can be solved by another level of > indirection" (David Wheeler) > > > I think we come back full cycle to your original solution of providing the > "Configuration" implementation itself as SPI. > > > But instead of providing an API to programmatically configure this central > point I'd really just make the 'Configuration' interface (or whatever we > call it) an SPI and provide a default implementation which uses the ordinal > base approach. > > And any user could (e.g. via ServiceLoader mechanism) provide it's own > algorithms for their application which would then totally replace the > default 'Configuration' implementation. This could be done for all use > cases where simply adding another ConfigSource is not enough. > > The benefits: > * easy use by default > > * unified configuration API from a users perspective (the code which needs > configured values) - regardless whether one uses the default Configuration > impl or an own. > > * as flexible as possible without having to add too much code into Tamaya. > > > LieGrue, > strub > > > > > > On Sunday, 28 December 2014, 13:53, Anatole Tresch <[email protected]> > wrote: > > > Lets see, but to some extent its obvious that we need a managing > component > > where things come together... > > Romain Manni-Bucau <[email protected]> schrieb am So., 28. Dez. 2014 > > um > > 11:52: > > > >> If we want such named configs we need a ConfigManager IMO exactly like > in > >> JCache. > >> Le 28 déc. 2014 00:04, "Anatole Tresch" > > <[email protected]> a écrit : > >> > >> > *Hi Mark* > >> > > >> > *see inline...* > >> > > >> > *Good night* > >> > *Anatole* > >> > ** > >> > > >> > 2014-12-27 21:01 GMT+01:00 Mark Struberg <[email protected]>: > >> > > >> > > > I see a chance that we are aligning now our ideas more and > > more ;) > >> > > > >> > > Yes, I see a lot or progress as well (on both sides). > >> > > > >> > > > >> > > > Basically you have to register > > PropertySourceProviderSpi's > >> > > Do you really need to? In DeltaSpike we just use the > > ServiceLoader > >> > > mechanism (has good support in SE, EE and even OSGi). > >> > > > >> > *-> That is what I meant, you still have to add a file with the > > given fq > >> > interface name under META-INF/services and add your entries. But this > >> > mechanisms fits for most areas ;) * > >> > > >> > > > >> > > In DeltaSpike the ConfigSourceProvider is actually optional. It > > is > >> there > >> > > for cases where you need to register multiple ConfigSources (e.g. > >> because > >> > > you have multiple property or ini files with the same name in > > various > >> > > JARs). Usually you don't use this but instead just natively > > register a > >> > > ConfigSource itself via the ServiceLoader mechanism. In that case > > there > >> > is > >> > > not a single line of code at all to register it. > >> > > > >> > > We don't need CDI nor anything else beyond pure Java. > >> > > > >> > *Theoretically, if people want to deploy things into the > > configuration > >> > part, which are loaded/needed, when CDI is available, they could also > > use > >> > CDI. Via BeanManager we have access to Instace and therefore we can > > read > >> > what is there. But it is a bit weired and using pure ServiceLoader is > >> > definitivly a good choise ;) * > >> > > >> > > >> > > Even when you have CDI you usually like to initialize the > > configuration > >> > > system _before_ you even start the CDI container. Otherwise we > > would > >> not > >> > be > >> > > able to utilize the config system for @Exclude-ing beans, > > deactivating > >> > > Extensions, etc. > >> > > > >> > > Thus you _always_ need to rely on the ServiceLoader mechanism. > >> > > > >> > *Agree, I never wanted to replace it, see above ;) * > >> > > >> > > > >> > > > >> > > > So for individual property sources (the ones != default) > > there > >> > > > >> > > > is no issue I think, because prioritization is not an issue > >> > > > >> > > Oh I think there is. I like to e.g. provide a default > > configuration for > >> > my > >> > > document archive connector. For easier maintenance I like to put > > them > >> > into > >> > > an own documentarchive.properties file which is packaged into my > >> > > documentarchive-connector.jar. This ConfigSource needs to get a > >> priority > >> > > which is higher than the very default ini and property files but > > lower > >> > than > >> > > the environment and system properties. > >> > > > >> > *My idea here was to register my own DocumentArchive > >> > propertysource/config, which is reading the custom property files and > > add > >> > defaults and overridings as useful by combining with the other > > (existing) > >> > property sources, e.g.* > >> > > >> > *PropertySource ps = > >> > > >> > PropertySourceBuilder.of("DocumentArchive"). > >> addProviders("system/default-all").addPaths("classpath: > >> META-INF/cfg/documentarchive.properties").addEnvironmentProperties(). > >> addSystemProperties().build();* > >> > > >> > *This configuration then would registered using the > >> > PropertySourceProviderSpi with ServiceLoader as top level property > > source > >> > and be accessible by calling:* > >> > > >> > *Configuration docCfg = > > Configuration.current("DocumentArchive");* > >> > > >> > > >> > > >> > > > >> > > Another use case would be to register a cluster wide ConfigSource > > which > >> > > reads from one of my application tables from the database. > > We've seen > >> > this > >> > > quite a few times in bigger projects. > >> > > >> > *For me having such a cluster-wide config in place is something that > > not > >> > the application-programme decides. It's the architecture that > > defines the > >> > mechanism and engineers it with Ops/Devs so it is working. When we > > have a > >> > usable environment it should be possible to evaluate the correct > >> > applicationId (and what else is required) which then can be used to > >> > connect to the config DB.* > >> > > >> > > >> > > >Level 1: globally the hierarchy of property sources, e.g. > >> > > > > >> > > > > >> > > >1. Boot Config, > >> > > >2. System config, > >> > > >3. Ear Config, > >> > > >4. App Config > >> > > >5. SaaS Config, > >> > > > >> > > This is a possible hierarchy dimension. But it is just ONE out of > > many. > >> > > Actually it's mixture between 2 different dimensions > >> > > a.) the time dimension:boot vs system (init) vs app (runtime) > >> > > b.) the modularity dimension: cluster vs container vs ear vs app > >> > > > >> > *Agree. Therefore we must have a flexible design, so basically every > >> kind > >> > of levels can be implemented. If we can identify hierarchies that > have > >> > shown to be common, we might think on providing them/or parts of them > > as > >> > extension modules. But I am not sure, if we really get there. > >> Definitively > >> > it is not a first prio stuff (adding the extensions), though we must > > have > >> > full fledged example of similar complexity to bullet-prove/show-case > > our > >> > ideas / design ;)* > >> > > >> > > > >> > > Whether a documentarchive.endpoint.url is needed at boot time or > > at > >> > > runtime is an implementation detail of my > > documentarchive-connector (to > >> > > stay at this example). > >> > > > >> > > >> > *Yep. But this max affect the location, where it must be configured. > > If > >> it > >> > is required during boot-time the configuration must of course also be > >> > available at that time ;)* > >> > > >> > Back when doing CODI (and then later again at DeltaSpike) we did > > discuss > >> > > this many times and found no good solution other than make a step > > back > >> > and > >> > > ignore _why_ people want the one over the other. The only thing > > we can > >> do > >> > > is to make sure that people (programmers, admin folks, etc) have > > a way > >> to > >> > > define the order in exactly the way they need. They don't > > even need a > >> way > >> > > to redefine the priority of the 'standard' ConfigSources > > (env, jndi, > >> > etc). > >> > > Instead they can just add their own ConfigSource with a higher > > ordinal > >> > and > >> > > be done. > >> > > >> > *Agree. Would state exact the same. Be as flexible as needed and > > let > >> > people do there crazy stuff, if they want to...* > >> > > >> > > > >> > > > >> > > > Looking at this level, priorities are IMO enough a feasible > >> > > > >> > > > mechanism, because it allows to easily add additional > >> > > > >> > > > layers transparently as needed ;) > >> > > While we still have a slightly different understanding about the > > 'why', > >> > we > >> > > DO agree about the result ;) > >> > > > >> > > But we really have to define which default ConfigSources we like > > to add > >> > > and which priority they should get. And we imo should not use 1, > > 2, > >> 3,.. > >> > > but like with @Priority for Interceptors we should start e.g. > > with 1000 > >> > and > >> > > keep big spaces in between them. Learned that with Basic in the > > early > >> > 80s... > >> > > > >> > *LOL, throwing me back at my old BASIC time. Save the queen,8,1 !!! > > Of > >> > course, completely agree!* > >> > > >> > > > >> > > Oh, for custom ConfigSources I actually don't care if the > > ConfigSource > >> > > itself knows it's ordinal or if the ordinal is set during > > registration > >> of > >> > > the ConfigSource. It is really very similar to the ELResolver > > chain > >> imo. > >> > > >> > *Yep. I would put on the provider side. So a PropertySourceProvider > > then > >> > would* > >> > *- register a top level property source* > >> > *- provide its priority needed to do the priorization* > >> > *- provide a property source as far it is avilable for the current > >> > environment* > >> > *- do whatever is needed internally (contextual management, > > classloader > >> > deps, caching etc). * > >> > * * > >> > *That way the programmatic combination case (the building SPI looks > > as a > >> > natural low level extension to this mechanism, if needed the same > >> mechanism > >> > could also be reapplied on level 2+).* > >> > > >> > > >> > > > I would not define priorities on single file level, but > > only on > >> > > property source level > >> > > > >> > > Actually in DeltaSpike each property file is an own ConfigSource. > >> > > > >> > *Often you define locations where files are to be located, such as > >> > META-INF/config/${STAGE}/**/*.xml . Bigger applications in Credit > > Suisse > >> > have dozens of such config files that are then combined to basically > 2 > >> > different main config trees. So you dont't know the exact file > > names > >> > before. Nevertheless in such cases we handle inconsistencies within > > such > >> a > >> > property source as "Deployment Error" because there is no > > good > >> resolution > >> > algorithm there. Also given that the exact ordering how files are > read > > is > >> > not relevant and the result will be reproducible.* > >> > > >> > > > >> > > Consider you have > >> > > > >> > > myframework.properties in the framework jar. Now I gonna use this > > jar > >> in > >> > > my application but like to slightly 'tweak' it's > > configuration. I just > >> > add > >> > > a myframework.properties to my own projects jar and give it a > > higher > >> > > ordinal (just add deltaspike_ordinal=1200 into the file). Voila. > >> > > >> > *I see here 2 use cases:* > >> > *1) the framework provides an explicit mechanism, how it enables > being > >> > overriden. Configuration hereby is part of the framework API. This > > could > >> be > >> > additional files on the classpath, or a named-configuration provided > > by > >> > Tamaya, or ... (perhaps you have more ideas)... That is the way I > > would > >> say > >> > it should work in most cases.* > >> > > >> > *2) we have a case, where we want to explicitly override things that > > are > >> > not meant being overridden. Due to security reasons you might want to > >> > prevent that this is possible, so it might be a better idea to handle > > is > >> as > >> > a special case. One variant could be to define a specific > >> > PropertySourceFilter/Interceptor API, where we explicitly can > override > >> > things, or we use the same priority overriding mechanism and add an > >> > additional PropertySourceProvider, with the same name, but higher > >> > priority.* > >> > > >> > *So assume we have "myframework-config" > > PropertySourceProvider with > >> prio > >> > 1000, we add a "myframework-config" PropertySourceProvider > > with prio > >> 1100. > >> > We could explicitly deny this feature for certain PropertySources, or > >> make > >> > it dependend on whatever conditions should be met. * > >> > > >> > *WDYT?* > >> > > >> > > >> > > > >> > > > >> > > > >> > > > Tamaya should be flexible enough to accomodate most of them, > >> > > > so application programmers still have their guides, where > >> > > > and how to add configuration files, resources etc. By adding > >> > > > >> > > > additional levels of configuration, e.g. on the deployment > > nodes, > >> > > > it is possible to override anything as needed. > >> > > With 'user' I was talking about the API. What you refer > > to is part of > >> the > >> > > SPI. And of course we will have this to add ConfigSources. > >> > > > >> > > > >> > > > >> > > > Summarizing I think we need both mechanisms. > >> > > > >> > > I still don't quite get this approach it seems. You have a > > default > >> > > configuration for the whole system which you get via > >> > > Configuration.current(), right? And you have a mechanism (builder > > like) > >> > to > >> > > tinker a different Configuration at runtime? Where do you store > > that? > >> > Where > >> > > do you use that? How to e.g. add graphical UI to allow admins to > > tweak > >> > > those settings? I still need a bit help to get the use case. What > > do > >> you > >> > > use it for usually? > >> > > > >> > *OK, hope that also some of the examples above help....* > >> > > >> > *Lets define a 2 level (for simplicity) source provider hierarchy:* > >> > > >> > - *"system" is provided globally once basically with a > > priority of > >> 1000 > >> > defined by PropertySourceProvider that registers it. Internally > >> > "system" is > >> > composed as follows (SPI code):* > >> > *private *PropertySource systemPS = > >> > PropertySourceBuilder.of("system") > >> > .addPaths("classpath:META-INF/cfg/**.xml", > >> > "classpath:META-INF/cfg/**.ini) > >> > > >> > > > .withAggregationPolicy(AggregationPolicy.IGNORE_DUPLICATES_AND_LOG) > >> > .addPaths("classpath:configs/*.conf") // > > legacy > >> location > >> > .addSystemProperties() > >> > .build(); > >> > - *"application" provides an isolated version, depending > > on the > >> > "applicationID" environment property. The corresponding > >> > **PropertySourceProvider > >> > **is added with a priority of 2000 for example and contains the > >> > following code (ignoring synchronization and cleanup for > > simplicity):* > >> > String applicationId = > >> > Environment.getInstance().get("applicationId"); > >> > if(applicationID==*null*) return *null*; > >> > PropertySource appPS = applicationConfigs.get( > applicationID); > >> > if(appPS==*null*){ > >> > appPS = PropertySourceBuilder.of("application") > >> > .addPaths("classpath:META-INF/ > >> cfg/"+applicationID+"/*.xml", > >> > > > "classpath:META-INF/cfg/"+applicationID+"/*.ini") > >> > > >> > > > .withAggregationPolicy(AggregationPolicy.IGNORE_DUPLICATES_AND_LOG) > >> > > > .addPaths("classpath:configs/"+applicationID+"/*.conf") > >> // > >> > legacy location > >> > > > .withAggregationPolicy(CustomRequestBasedOverrides.of()) > >> > .addProvider(new > >> > MyApplicationRequestPropertySourceProvider()) > >> > .build(); > >> > } > >> > return appPS; > >> > > >> > *The user will not see any kind of these hierarchy, but simply > access > >> > Configuration.current(). But for me the building of the internals of > > the > >> > provided building blocks is much more natural and flexible using the > >> > builder pattern...* > >> > > >> > *Now it's your turn again ;)* > >> > > >> > > >> > > >> > > >> > > > >> > > > >> > > LieGrue, > >> > > strub > >> > > > >> > > > >> > > > >> > > On Saturday, 27 December 2014, 18:47, Anatole Tresch < > >> [email protected] > >> > > > >> > > wrote: > >> > > > > >> > > >Hi Mark > >> > > > > >> > > > > >> > > >I will try to answer as precise as possible. I see a chance > > that we > >> are > >> > > aligning now our ideas more and more ;) > >> > > >... (inline) > >> > > > > >> > > > > >> > > >2014-12-27 16:26 GMT+01:00 Mark Struberg > > <[email protected]>: > >> > > > > >> > > >Hi Anatole! > >> > > >> > >> > > >>First of all thanks for sharing this sample. You might > > know your use > >> > > cases but others don't. > >> > > >>I assume that all this PropertySource construction is > > done at a > >> single > >> > > point, e.g. a producer metho > >> > > >> > >> > > >Yes, but that is only the access point, read ahead... > >> > > > > >> > > >Let me ask a few questions: > >> > > >> > >> > > >>1.) How do you know which ConfigSources exist in the > > project? You > >> might > >> > > be one jar in a dozen ones, having no control over them? > >> > > >> > >> > > >Basically you have to register > > PropertySourceProviderSpi's (or > >> whatever > >> > > they are named) with your code. How these are loaded depends on > > the > >> > > ServiceContext, so in SE you will probably use ServiceLoader > > only, > >> > whereas > >> > > in EE you can additionally rely on CDI to resolve corresponding > >> sources. > >> > > And as you said there could be multiple ones, which are visible > > in a > >> > > certain context depends on the ServiceContext. So for individual > >> property > >> > > sources (the ones != default) there is no issue I think, because > >> > > prioritization is not an issue, additionally individual configs > > can > >> also > >> > > use other existing ones in their metamodel, if needed (in the > >> definition > >> > > code of the provider itself). > >> > > > > >> > > > > >> > > >Level 1: globally the hierarchy of property sources, e.g. > >> > > > > >> > > > > >> > > >1. Boot Config, > >> > > >2. System config, > >> > > >3. Ear Config, > >> > > >4. App Config > >> > > >5. SaaS Config, > >> > > > > >> > > > > >> > > >I assumed that this hierarchy is well defined in an > > environment, and > >> > > typically not dynamic during runtime and therefore yes, hardcoded > > in > >> the > >> > > metamodel loaded on boot level. I even think from a security > >> perspective > >> > it > >> > > is not a good idea to have it dynamically. A provider may not > > be > >> > > available (based on the environment), so when executing a MDB in > > the > >> ear > >> > > it might be only the following sources are available/actively > >> providing > >> > > data to the current configuration: > >> > > > > >> > > > > >> > > >1. Boot Config, > >> > > >2. System config, > >> > > >3. Ear Config, > >> > > > > >> > > > > >> > > >Looking at this level, priorities are IMO enough a feasible > > mechanism, > >> > > because it allows to easily add additional layers transparently > > as > >> > needed ;) > >> > > > > >> > > > > >> > > >Now, what a Level 1 PropertySource is doing internally is > > completely > >> > > another story. Here in that area I expect more fine grained > > aggregation > >> > > operations to be used in many cases, as suggested in the example. > >> > > Additionally a PropertySourceProviderSpi is allowed to provide > > the > >> > > effective property sources contextually, e.g. depending on the > > current > >> > > classloader visiblity of items. > >> > > > > >> > > > > >> > > >So given that I adding a priority to a PropertySource is an > >> interesting > >> > > aspect. I even would ask, if we have one, if it would make sense > > to > >> > provide > >> > > some admin functionality to change the priority during runtime, > > or > >> adding > >> > > additional sources on the fly. When I am using the builder, > > priorities > >> > are > >> > > normally ignored, whereas for the overall configuration > > hierarchy, they > >> > are > >> > > useful. Additionally we also can use the priorities as well on > > Level 2 > >> > and > >> > > beyond, as useful ;) > >> > > > > >> > > > > >> > > >Summarizing I think we need both mechanisms. > >> > > > > >> > > > > >> > > > > >> > > > > >> > > >2.) In DeltaSpike each property file could define it's > > own ordinal > >> with > >> > a > >> > > simple entry in the property file. That way you can just add a > > JAR > >> which > >> > > overrides a default config from another jar. Would each of them > > get an > >> > own > >> > > name? Or do they all share the same name and priority? > >> > > >> > >> > > >I would not define priorities on single file level, but only > > on > >> > property > >> > > source level. I can still an additional property source and > > override > >> the > >> > > keys I want on source level. But as I said, do we really want > >> application > >> > > deploy an additional jar, hereby completely overriding any kind > > of > >> > config. > >> > > I would say, no. But we can define (company specific mechanism), > > how > >> and > >> > > when config can be overridden as part of the metamodel. > >> > > > > >> > > >3.) How do you deal with modularity? E.g. adding a dependency > > which > >> > needs > >> > > some other ConfigSource but knows nothing about your code? > >> > > >> > >> > > >>4.) Another modularity question: What about having > > multiple jars > >> > > (different independent framework parts) and each of them likes to > > have > >> > > another PropertySouceBuilder configuration? > >> > > >> > >> > > >Use different property source names on top level. > >> > > > > >> > > > > >> > > > > >> > > >>5.) How do you allow containers and framework programmers > > to add > >> > > PropertySources which affect all the project? > >> > > >>They define the metamodel and the extension points by > > the > >> > > implementation of the configuration metamodel. This metamodel as > > I > >> said > >> > > should not be dynamic. > >> > > >> > >> > > >>6.) > >> > > >> > >> > > >>> - you can override along the classloader hierarchy > > (system, ear, > >> war) > >> > > >> > >> > > >>> by adding resources to the classpath at xxx.Usually > > this does not > >> > work > >> > > well as e.g. all the JARs in WEB-INF/lib have exactly the same > > 'level'. > >> > > It's totally up to the ClassLoader mechanism in which order > > you get > >> them. > >> > > And that could change on every restart. Been there, done that - > > doesn't > >> > > work. > >> > > >> > >> > > > > >> > > >I would never rely on the classloader ordering. Normally > > your config > >> > > within such a level should be consistent. If not you have > > multiple > >> > > possibilities: > >> > > >1) just take one. > >> > > >2) Just take one and log. > >> > > >3) throw a Deployment Error > >> > > >4) take a default > >> > > >5) Override the conflicting value on the next level of > > defined > >> config, > >> > > so the conflict is not relevant anymore. How this is done, is > > defined > >> by > >> > > your metamodel. > >> > > > > >> > > > > >> > > > > >> > > >7.) > >> > > >>> In code the do simply: Configuration config = > >> > > >>> Configuration.current("Stephen"); > >> > > >>And what if another jar does > > Configuration.current("Giovanni")? > >> > > >>Imo that approach doesn't scale. > >> > > >> > >> > > >> > >> > > >Normally you do Configuration.current(); // the default > >> > > > > >> > > > > >> > > >Configuration.current("name") is for specific > > isolated/modular > >> > > configuration sources (see 3). > >> > > > > >> > > > > >> > > >>I like to align our ideas, so I enumerate my main goals > > and design > >> > > principles of a config system as I envision it: > >> > > >> > >> > > >>A.) have a total separation between the configuration > > system and it's > >> > > consumers. The 'consumers' API should not know where the > > result comes > >> > from > >> > > and also not what the value is. I think this is the only way we > > can > >> > provide > >> > > an extensible system where e.g. the Operations team could > > 'overwrite' > >> > > certain values. If we require the userland code to know about the > >> > > PropertySources then we cannot do this. > >> > > >> > >> > > > > >> > > > > >> > > >Partially agree. Companies have their own way how they > > configure > >> their > >> > > applications. Tamaya should be flexible enough to accomodate most > > of > >> > them, > >> > > so application programmers still have their guides, where and how > > to > >> add > >> > > configuration files, resources etc. By adding additional levels > > of > >> > > configuration, e.g. on the deployment nodes, > >> > > >it is possible to override anything as needed. The ladder, > > yes, should > >> > be > >> > > completely transparent. > >> > > > > >> > > > > >> > > >B.) Have a flexible SPI to allow Container Vendors and also > >> > application > >> > > programmers to add their own PropertySources in a very easy way. > >> > > >> > >> > > >Yes and no (see security constraints). I think we have to > > discuss > >> more > >> > > deeply the roles involved and what should be possible. > >> > > > > >> > > >C.) The SPI should be extensible via plugin mechanism. If a > > jar > >> > > containing a PropertySource gets added then it should > > automatically get > >> > > picked up for this very application. > >> > > >> > >> > > >If the metamodel foresees that to be so, yes. If not, not > > (see > >> > > secuirity...). > >> > > > > >> > > >Are we on the same page here? > >> > > >> > >> > > >> > >> > > > > >> > > > > >> > > >I hope! > >> > > > > >> > > > > >> > > >LieGrue, > >> > > >>strub > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >>> On Saturday, 27 December 2014, 15:35, Anatole Tresch > > < > >> > > [email protected]> wrote: > >> > > >>> > Hi Gerhard > >> > > >>> > >> > > >>> all you say is true here, I also will not provide > > every kind of > >> > > combination > >> > > >>> logic, but I want to have a mechanism that is > > capable enough. > >> > > >>> > >> > > >>> @Mark end users don't see this mechanisms here. > > It used by the > >> power > >> > > users, > >> > > >>> which define the "metamodel" how/where > > configuration is read > >> > > >>> and assembled, e.g. > >> > > >>> > >> > > >>> SPI: PropertySourceProvider { > >> > > >>> Collection<PropertySource> > > getPropertySources(); > >> > > >>> } > >> > > >>> > >> > > >>> Lets assume the provider is returning one property > > source named > >> > > >>> "Stephen". > >> > > >>> The power user would then probably write something > > like that: > >> > > >>> > >> > > >>> PropertySource src = > >> > > >>> > > PropertySourceBuilder.of("Stephen").addProviders(myProv2, > >> > > >>> myProv3).withAggregationPolicy(mySpecialPolicy) > >> > > >>> > >> > > >>> > >> > > > >> > .addProvider(BranchSpecificOverrideFilter.getPropertySource()). > >> withAggregationPolicy(AggregationPolicy.OVERRIDE_AND_LOG) > >> > > >>> > > .addProvider(DefaultJavaEEProviders.getEarProvider()).build(); > >> > > >>> > >> > > >>> This src instance then is returned e.g. by the > > provider (could also > >> > be > >> > > >>> contextually per classloader etc.). So it is not > > only that the > >> > > mechanism is > >> > > >>> much more explicit and powerful, it > >> > > >>> is also easier to understand. There is exactly one > > location, where > >> > all > >> > > >>> happens: the PropertySourceProvider. You look at the > > code and > >> > > immediately > >> > > >>> now, what is happening. > >> > > >>> So the code that is assembling the final property > > source returned > >> is > >> > > under > >> > > >>> full control of the users and nicely explicit. > >> > > >>> > >> > > >>> For normal users the mechanism is completely > > transparent the will > >> > > typically > >> > > >>> have some kind of documentation, where its written: > >> > > >>> > >> > > >>> - put your config files in the formats .ini or .xml > > at the location > >> > xy > >> > > >>> - you can override along the classloader hierarchy > > (system, ear, > >> war) > >> > > by > >> > > >>> adding resources to the classpath at xxx. > >> > > >>> - Branch sepcific overrides are merge automatically > > into it, see > >> > > chapter > >> > > >>> 3.4 for additional details. > >> > > >>> - Finally it is possible to override entries an > > system leven, by > >> > > setting > >> > > >>> according system properties. > >> > > >>> > >> > > >>> In code the do simply: Configuration config = > >> > > >>> Configuration.current("Stephen"); > >> > > >>> > >> > > >>> You get it? > >> > > >>> > >> > > >>> > >> > > >>> > >> > > >>> 2014-12-27 15:13 GMT+01:00 Gerhard Petracek < > >> > > [email protected]>: > >> > > >>> > >> > > >>>> hi anatole, > >> > > >>>> > >> > > >>>> i guess everybody agrees that overriding based > > on ordinals > >> wouldn't > >> > > be > >> > > >>>> enough for every possible use-case. > >> > > >>>> back then we had a long discussion about it. we > > ended up with > >> > adding > >> > > a > >> > > >>>> simple (and optional) ConfigFilter interface. > >> > > >>>> > >> > > >>>> @aggregation: > >> > > >>>> aggregation of key/value pairs is supported > > implicitly by an > >> > ordinal > >> > > based > >> > > >>>> approach. > >> > > >>>> aggregation of values >per key< can be > > done manually with an own > >> > > >>>> config-source (which delegates to the others > > and only aggregates > >> > > those > >> > > >>>> results). > >> > > >>>> yes - that way this use-case is more > > complicated out-of-the-box. > >> > > however, > >> > > >>>> imo if users (think they) need such a > > complicated config, they > >> > > should also > >> > > >>>> need to do a bit more for it. > >> > > >>>> (i guess in several cases they might question > > the requirement > >> > before > >> > > they > >> > > >>>> continue...) > >> > > >>>> > >> > > >>>> in general about possible use-cases (and > > features): > >> > > >>>> we can never address everything out-of-the-box. > >> > > >>>> a nice example is bean-validation. i could list > > a lot of cases > >> > which > >> > > >>> aren't > >> > > >>>> possible with that api/spi out-of-the-box, > > however, for the > >> > majority > >> > > >>> it's > >> > > >>>> good enough. > >> > > >>>> i saw several users who couldn't replace > > their existing > >> > > >>> validation-approach > >> > > >>>> (as it was). > >> > > >>>> however, several of them just simplified their > > validation-logic > >> and > >> > > were > >> > > >>>> still happy about the result. > >> > > >>>> others extended bv e.g. via the spi and only > > few kept what they > >> > used > >> > > before > >> > > >>>> (e.g. because it wasn't possible with bv or > > the workaround was > >> too > >> > > >>>> complicated > >> > > >>>> and they insisted on what they had). > >> > > >>>> > >> > > >>>> regards, > >> > > >>>> gerhard > >> > > >> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >> > >> > > > > >> > > > > >> > > > > >> > > > > >> > > >-- > >> > > > > >> > > >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/ > >> > > >Google: atsticks > >> > > >Mobile +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* > >> > > >> > > >
