BTW: turning PropertyProviders into a builder I think could be a good idea...
So one could write something like
PropertyProvider provider = PropertyProviderBuilder.create("myconfig")
.add("classpath*:ksdhksdh")
.with(AggregationPolicy.OVERRIDE)
.add ("file:myfileLocation")
.aggregate(AggregationPolicy. OVERRIDE,
PropertyProviderBuilder.create("dbConf").add("jdbc:myConfig.format1?dialect=oracle")
.with(AggregationPolicy.OVERRIDE).addSystemProperties().build())
.build();
WDYT?
-----Original Message-----
From: Werner Keil [mailto:[email protected]]
Sent: Mittwoch, 3. Dezember 2014 13:16
To: [email protected]
Subject: Re: Use Case 1: Read simple properties and get values.
I would go a bit beyond a simple "ConfigFormat" based on the experience
with Multiconf in a very large Cloud environment.
What was used there aside from obvious (JSON) data exchange or output one
might consider "format" is more towards "ConfigReport" or whatever you
might call that.
We used Asciidoc and with several Asciidoc and Asciidoctor affine members
here I guess that could also work for Tamya;-)
Werner
On Wed, Dec 3, 2014 at 1:08 PM, Tresch, Anatole <
[email protected]> wrote:
> @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
> >> >
> >>
>
