Hmm, there is something fishy fo rme in this reader/format/... discussion.
>From your description I would expect:
PropertyProviders.fromPath("reader[:format]whatever"); to be
supported. And if it is what there is behind the scene I would like it
to be part of the API.
One simple use case: support properties, yaml, ini, xml or whatever
just be called myconfig.conf or myconfig.config or any other
extension.
I agree we can guess the format from the extension often enough to not
force its usage but since it is important as you mentionned it I think
we need to accept it is part of the API.
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-03 14:02 GMT+01:00 Werner Keil <[email protected]>:
> The Asciidoc reporting is not part of the Open Source project AFAIK, but
> here's Multiconf on GitHub:
> https://github.com/lhupfeldt/multiconf
>
> For those familiar with scripting languages like Groovy Python should not
> feel too strange;-)
> Here a quick example on how it can be used:
>
> # Define environments
>
> # Use EnvFactory() to create environment or group of environments
> ef = EnvFactory()
>
> # We have five environments and we define them here
> devlocal = ef.Env('devlocal')
> devi = ef.Env('devi')
> devs = ef.Env('devs')
> preprod = ef.Env('preprod')
> prod = ef.Env('prod')
>
> # Grouping environments per their roles
> g_dev = ef.EnvGroup('g_dev', devlocal, devi, devs)
> g_prod = ef.EnvGroup('g_prod', preprod, prod)
>
>
> # This function is used to describe all environments and return an
> instantiated environment
> # configuration for environment with name 'env_name', which is passed as
> parameter
> def conf(env_name):
> env = ef.env(env_name)
>
> # This will define a weblogic configuration for all environments
> defined above
> # But the result of execution of conf() will be the setting for
> environment
> # passed as argument 'env_name'
> # Use EnvFactory 'ef' to define the required/allowed environments
> # The 'weblogic_config' class is defined in framework.py
> with weblogic_config(env, ef) as dc:
> # Set domain base port number for different environments.
> # Domain base port is used as base to calculate port offsets
> # Here we're saying that Weblogic in g_prod group will have
> # attribute base_port set to 7000, and each of the development
> environments
> # will have unique base_port
> dc.setattr('base_port', g_prod=7000, devi=7100, devs=7200,
> devlocal=7300)
> [...]
>
> The "DSL" for configuration is almost entirely done in Python, thus could
> be compared to annotated Java code where we support that. Multiconf
> generates al sorts of files like XML (for WLS and other containers) but
> configuration itself is barely done or overridden via XML.
>
> We may have a slightly broader scope but some aspects and goals are pretty
> similar.
>
> Werner
>
> On Wed, Dec 3, 2014 at 1:19 PM, Tresch, Anatole <
> [email protected]> wrote:
>
>> Can you explain (or post a link) that in more detail, people might not now
>> much about Multiconf...
>>
>> -----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
>> > >> >
>> > >>
>> >
>>
