Hi all
basically yes, the only difference is that it gets its input source from
outside, whereas a property provider knows it by itself.
But that doesn't matter. I am personally not yet satisfied with the
ConfigurationFormat interface, since I also miss some aspects and don’t have
any good idea how to solve it:
· a format itself should not know anything about priorities, but this
is needed to create correct PropertySource instances.
· a format can read a file which contains entries with different
priorities, so I want to reconfigure the default priorities as needed.
One of my ideas would be at the end to do something like that:
MyPropertyProvider extends AbstractPathBasePropertyProvider{
...
super.addFormats(properties, iniFormat, legacyXmlFormat);
super.setPaths("META-INF/cfg/default/**/.properties","META-INF/cfg/default/**/.xml","META-INF/cfg/default/**/.ini");
}
So it makes it very easy to just define where your configs is and which format
you are able to interpret.
So it might be better to introduce something like a
Map<Map<String,String>> readConfiguration(URL url)
throws IOException;
where I return all the entries found and, but return a separate map, identified
by the type of entries collected. But this still looks ugly…
That way at least a consumer can still decide what to do with the properties
read and create different PropertySources (or whatever) as needed.
So this is not mature enough. Perhaps I will come up with a better proposal
later or one of you guys has a better idea…
-Anatole
-----Original Message-----
From: Romain Manni-Bucau [mailto:[email protected]]
Sent: Dienstag, 6. Januar 2015 10:30
To: [email protected]
Subject: Re: How to find configuration resource?
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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
>> >> > S oliver.b.fischer
>> >> > J [email protected]<mailto:[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*
