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 > > >
