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*
