Looks very close to property source provider, does it worth duplicating it or is it just somthing which can reused provider logic/API (in extensions).
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-06 10:23 GMT+01:00 Anatole Tresch <[email protected]>: > OK, I was not aware of that constructor. So I agree for resource > abstractions we can use URL, if nobody else sees any issues with that. > So we only must think on the logic to resolve a pattern to multiple URLs, > but that can be handled as an extension IMO. > > Nevertheless the question is in the room, if we dont want to add an > abstraction for a ConfigurationFormat, consuming an URL and returning a set > of PropertySources. Given that PropertyFileFormat and PropertyFileXmlFormat > can implement that interface already as part of core and it can be used in > other areas, e.g. when providing builders and helper to ease > defining/implementing PropertySourceProvider instances. Currently it is > defined as > > @FunctionalInterface > public interface ConfigurationFormat { > > /** > * Reads a list {@link org.apache.tamaya.spi.PropertySource} instances > from a resource, using this format. > * If the configuration format only contains entries of one ordinal > type, normally only one single > * instance of PropertySource is returned. Nevertheless custom formats > may contain different sections or parts, > * where each part maps to a different target rdinal (eg defaults, > domain config and app config). In the > * ladder case multiple PropertySources can be returned, each one with > its own ordinal and the corresponding > * entries. > * > * @param url the url to read the configuration data from (could be a > file, a remote location, a classpath > * resource or something else. > * @return the corresponding {@link > org.apache.tamaya.spi.PropertySource} instances, never {@code null}. > */ > Collection<PropertySource> readConfiguration(URL url) > throws IOException; > > } > > > That was also my idea, why I added this feature originally to core.... > > Best > Anatole > > > > 2015-01-06 10:13 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> You can also use the constructor: java.net.URL#URL(java.lang.String, >> java.lang.String, int, java.lang.String, java.net.URLStreamHandler). >> >> That said maybe you can start by proposing some cases where URL is not >> enough, IMO it covers 90% of cases and it doesn't worth adding >> something new for the last 10ù which can be solved with a custom >> handler but maybe I miss a use case where "Resource" would bring >> something. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-06 10:08 GMT+01:00 Anatole Tresch <[email protected]>: >> > I don't think the discussion is finished. Oliver has restarted it with >> this >> > thread! >> > >> > I already said that URL has some good concepts. but its a class (not an >> > interface as I would expect) and it lacks of flexibility: Adding >> additional >> > protocols AFAIK requires me to implement URLStreamHandlerFactory (and >> with >> > that an URLStreamHandler and a URLConnection). I can register this by >> > setting a system prop 'java.protocol.handler.pkgs' (ugly!) or by calling >> > URL#setURLStreamHandlerFactory(f). Unfortunately the ladder method is >> > documented to be called mostly once, which may easily conflict with other >> > stuff running in the system. So the extendability of URL is very limited >> > and cumbersome IMO. >> > >> > >> > 2015-01-06 8:55 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> > >> >> +1 for the URL, IMO no need of any more abstraction here for now. If >> >> you need a "locator" then json property source is broken since it is >> >> already the format so it only needs the input stream - URL is a nice >> >> way to abstract it and easy to get from File, classloader, http... >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-06 8:29 GMT+01:00 Oliver B. Fischer <[email protected]>: >> >> > Dear all, >> >> > >> >> > we have to clarify how do we find a property source at the end of the >> >> day. I >> >> > have seen now three different apporaches: >> >> > >> >> > 1. org.apache.tamaya.format.ConfigurationFormat interface by Anatole >> >> > 2. Using an URL by Reinhard >> >> > 3. Custom interface by me for the JSON PropertySource >> >> > >> >> > The solution by Anatole and me is very similar and could be unified >> >> easily. >> >> > Independent of the way we go this interface belongs to the core >> module. >> >> Or >> >> > not? >> >> > >> >> > Furthermore how does a normal Java SE user will use it? How does the >> top >> >> > level usage of Tamaya looks like? >> >> > >> >> > Oliver >> >> > >> >> > >> >> > -- >> >> > 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* >> > > > > -- > *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*
