Hi Antole, my problem is simply that I dont know which PropertySources do exist. There might be 0 to x possible PropertySources available in the classpath. So the question is how to I detect them and the method I have to call with the given URL.
Von meinem iPhone gesendet > Am 12.02.2015 um 19:56 schrieb Anatole Tresch <[email protected]>: > > 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 >> >>
