@Romain
The concept is - as I said - that you can describe, from which source a
configuration should be read. This descriptions goes first to a reader, which
knows how to resolve the location and resolves to a number of URIs/input
streams.
These input streams can come in multiple formats (even mixed). Configuration
Format and reader are the abstraction so you can write basically something like
PropertyProvider prov = PropertyProviders.fromPath("reader:whatever");
In the example above you can declaratively define a PropertyProvider, fast and
easy, and you (by default) do not have to care on the format (BTW it is
possible that multiple formats register for the same file ending).
Removing ConfigFormat means, that you
- only support a limited set of formats, or
- must implement format parsing logic yourself also for the most common cases,
and
- create additional implementation dependencies on the format parsing code
- and probably you have to duplicate the logic that converts an InputStream
into a Map<String,String>/ProeprtyProvider.
Finally: the project is internally split up into an API part and an
implementation part. ConfigFormat is not part of the API (you typically will
not code against it). If you have really want to write all your providers
yourself, you can do that. Nobody prevents you doing so, but please allow other
maybe less sophisticated users to benefit from provided features, so they do
not have to write them themselves.
And once more, this feature was a great help for supporting muiltiple formats
such as .properties, .xml (xml-properties), .ini (ini-Files). I do not see any
reason we should remove something that has proven to work so nicely.
Cheers,
Anatole
-----Original Message-----
From: Romain Manni-Bucau [mailto:[email protected]]
Sent: Mittwoch, 3. Dezember 2014 12:18
To: [email protected]
Subject: Re: Use Case 1: Read simple properties and get values.
I don't fully agree. Where is passed through PropertyProviders so
basically we don't need this format abstraction. Providers should just
check it can read it or not. having such an indirection already makes
the framework "apparently" complex enough to not be used from my point
of view.
Implementing a custom provider to read what you want is generally
trivial enough to be where the extenisbility is.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 12:13 GMT+01:00 Anatole Tresch <[email protected]>:
> Far this is not the same. A provider defines where configuration is read.
> The format defines how. Even properties files may lay at multiple
> locations, could be locally , classpath, blobs, remotedly, ... I want to
> support users that they are able to read configuration with minimal coding
> required.
>
> This model is flexible and is the reason we reading in uc1 is so simple and
> will be similar easy also for enterprise specific custom formats. Companies
> will never change their existing formats just to use Tamaya...
> Romain Manni-Bucau <[email protected]> schrieb am Mi., 3. Dez. 2014 um
> 11:45:
>
>> +1, ConfigFormat or PropertyProvider shouldn't be there.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-03 8:37 GMT+01:00 Oliver B. Fischer <[email protected]>:
>> > So if a new ConfigFormat is required for reading a different data source:
>> > What is the difference between ConfigFormat and PropertyProvider? Isn't
>> it
>> > the same?
>> >
>> > IMHO we have to discuss the overall architecture a least a little bit to
>> see
>> > which parts exist, how they interact and who is responsible for what.
>> >
>> > Oliver
>> >
>> > Am 03.12.14 01:15, schrieb Anatole Tresch:
>> >>
>> >> BTW, supporting a new ConfigFormat is trivial: implementing
>> >> ConfigurationFormat
>> >> and register it with as component, by default using the ServiceLoader.
>> >> Then you only to read the file and you are done ;)
>> >>
>> >> 2014-12-01 19:48 GMT+01:00 Gerhard Petracek <[email protected]
>> >:
>> >>
>> >>
>> >
>> > --
>> > 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
>> >
>>
