Look at the resources extension. It supports Spring styled path resolution to a collection of URLs. Will work in SE, Weblogic, and basically should also in JBoss/Wildfly, but must be tested there since the guys have some interesting classloader design there, which must be handled differently... Basically the extension register another service called ResourceResolver to the ServiceContext.... so we are back to my second original proposal using formats as well ;)
2015-02-12 20:40 GMT+01:00 Oliver B. Fischer <[email protected]>: > 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 > >> > >> > -- *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*
