Don't mix up *@Priority* with the ordinal() method on *PropertySource*. For property sources I think the method is the better solution, since it can dynamically assigned, e.g. based on the file's content. For more complex cases you also have the *PropertySourceProvider*, which can register multiple ** *PropertySource *instances. As a more complex examples see at the following config file:
<config> <defaults> <a.b.c.value>MyValue</a.b.cValue> </defaults> <domainOverrides> <myArea> <myValue1>123</myValue1> <myValue2>3434.56</myValue2> </myArea> <server> <ip>1.2.3.4</ip> <overrides> < a.b.c.value>anotherMyValue</a.b.c.value> </overrides> </server> </domainOverrides> </config> Such a file cannot be mapped to a single *PropertySource*, since it contains entries with differing priorites in the same file (note: this is not a hypothetic example, I've seeen such solutions multiple times). In that case we would implement a *PropertySourceProvider *that parses the file, sorts the different entries into corresponding collections and then returns a PropertySource for each non empty list of entries. Such cases only can be solved by custom implementations, but good news: this is the top of complexity in the basic overriding area (e.g. Credit Suisse config, which is one of the most complex I've seen so far, fits into this system quite well). Nevertheless we can still support file paths etc, A file path then will resolve to at least one PropertySource per file resolved, or even (as shown above) to multiple property sources per file. In a big application like Credit Suisse has, you will end up likely with 200 property sources at the end. But this is not bad per se. For example we can access all property sources a system consumes (also the ones with overriden entries) and that way have a real traceability of what is happening (a very important aspect). The @Priority is more meant for priorizing other registered services, for example adapters, expressions resolvers etc. -Anatole Romain Manni-Bucau <[email protected]> schrieb am Mon Dec 29 2014 at 14:59:16: > you are right if you expect N (N>>1) configurations. More I think to > it more I guess we'll have very few providers/sources in practise. > basically JVM ones (built-in like system properties + a default > properties file) + a custom one. I wouldn't expect more (for > maintenance, simplicity and understanding of the system). In this case > priority works. That said nothing prevents you to extend > BasicPropertyProviderImpl to specify another priority if needed but if > you have multiple file you surely dont put the same thing inside. So > is it a real issue? > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2014-12-29 14:52 GMT+01:00 John D. Ament <[email protected]>: > > On Mon Dec 29 2014 at 8:06:07 AM Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> provided impl can have a hardcoded priority so not an issue (finally > >> @Priority value is stored in a map or any data structure and never > >> used directly so we can directly do it for internal impls) > >> > > > > Right, but then if I have two instances of (say > BasicPropertyProviderImpl) > > that look at two different files, they'll end up with the same priority. > > > > I just don't think the priority annotation works well here. > > > > > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2014-12-29 13:40 GMT+01:00 Werner Keil <[email protected]>: > >> > It depends, whether you need an extra annotation in that case. > >> > Sometimes a good old numeric priority could also do. > >> > > >> > Werner > >> > > >> > On Mon, Dec 29, 2014 at 1:34 PM, John D. Ament <[email protected] > > > >> > wrote: > >> > > >> >> On Sun Dec 28 2014 at 7:06:22 PM Mark Struberg <[email protected]> > >> wrote: > >> >> > >> >> > Hi! > >> >> > > >> >> > Anatole and I are currently discussing whether it is worth it > adding > >> >> > @Priority or not. > >> >> > > >> >> > >> >> Depends on what issue you're trying to solve. If it's to assign > >> priority > >> >> to a config source, it probably wouldn't work since some of the impls > >> are > >> >> provided by tamaya. > >> >> > >> >> > >> >> > > >> >> > It would make a few interfaces more elegant but this also has one > >> >> > downside. This version of JSR-250 is not yet in JavaSE by default. > Of > >> >> > course it is needed for all JavaEE7++ servers. > >> >> > > >> >> > The question now is whether we can burden our users to add > >> >> > commons-annotation-1.2 in SE? > >> >> > > >> >> > LieGrue, > >> >> > strub > >> >> > > >> >> > >> >
