Hi Oliver How should your spi fit into what we have? You register either propertysources or propertysourceprviders.you can implement a propertysourceprovider that eg reads another config or cli param and creates the corresponding propertysources.they way you do it, you either have hardcoded the priority or read it from the file. Also your mapping from your config file to key/values is clearly defined imo. So for me this looks like a fairly trivial use case. Now in huge j2ee environments you have config that has different prios depending it is a file, a system property or a classloader. Even the classloader hierarchy itself has multiple levels/prios. Finally there is not necessarily a unique mapping to key/value pairs. Even when using simple ini files different sections may not be part of the key at all, instead they may named "defaults", "system", "app", "ops", "management". Each maps to a different prio, so you have 1-n mapping between url and propertysource. This is not reflected by your spi proposal at all (but covered by my current work). Hope that helps... ;-) Oliver B. Fischer <[email protected]> schrieb am Do., 12. Feb. 2015 um 19:04:
> Hi Anatole, > > IMHO the suggest SPI is the solution you expected. With this SPI I can > implement a proper URL support without any hardcoded stuff. Ok, the > implementation of the SPI knows how to instantiate it's PropertySource. > But since both are provided by the same module/author/extension this is > ok IMHO. > > But let me cite the JavaDoc of PropertySource > > This interface models a provider that serves configuration properties. > The contained > properties may be read fromMap single or several sources (composite). > PropertySources are the building blocks of the final configuration. > > So from the perspective of PropertySource it is ok if the PropertySource > is responsible for reading and parsing it's source. > > As I said in my initial post: The only think except for array support is > a link between a URL and a PropertySource. > > So please give me a runnable example with the code as it is today how I > can do it in an generic way. > > Bye, > > Oliver > > > > Am 12.02.15 um 18:13 schrieb Anatole Tresch: > > Ho Oliver > > > > O do noz get your point, see inline... > > > > 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <[email protected]>: > > > >> Why is it so fucking hard to do easy things easily? ;-) > >> > >> Here is an example implementation for th JSONPropertySource > >> > >> public class JSONPropertySourceLocator implements PropertySourceLocator > { > >> @Override > >> public PropertySource get(URL source) { > >> if (!accepts(source)) { > >> String mesg = format("%s is not supported", > source.toString()); > >> throw new ConfigException(mesg); > >> } > >> > >> return new JSONPropertySource(source); > >> } > >> } > >> > >> 1) who is providing the URLs ? > > 2) Checking for an URL, if it is accepted, most of the time is a format > > issue IMO only. So your code above basically > > dies the same as a format, but unfortunately on top mixes it with a > > PropertySource. > > > > > >> Adding a PropertySourceProviderManager is not helpfull because it has to > >> discover existing format (Anatoles approach) or > > This is not true. My example PropertySource can as well use exactly one > > single format, but also is fkexible enough to support multiple ones. BTW > > also a precondition, when you want to be able to integrate alternate > format > > implementations such as commons-configuration ;) > > > > > > > >> existing PropertySource implementation. Every PropertySource must be > >> scanned for an ctor with URL parameter and so on and so on. This is not > an > >> very flexible design.. > >> > > As I said, I am also not completely satisfied with everything related to > > that, but when doing some criticiscm of things being inflexible, also be > > aware that I expect you to provide some ideas how to improve it, Mixing > up > > formats (the act of parsing), with the act of mapping the parsed data to > a > > flat key, value structure and assigning (depending on the file location, > > the file entries and whatever else) the correct priority for every > > key/value pair, are three aspects that each one must be decided on its > own. > > Hardcoding anything makes no sense from a framework perspective (but may > be > > from an enterprise perspective)... > > > > > >> Bye, > >> > >> Oliver > >> > >> > >> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau: > >> > >> -- > >> N Oliver B. Fischer > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >> P +49 30 44793251 > >> M +49 178 7903538 > >> E [email protected] > >> S oliver.b.fischer > >> J [email protected] > >> X http://xing.to/obf > >> > >> > > > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf > >
