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 >> >> > >> >> >>
