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