Makes sense, that is also why you don't find the reporting part in the core Open Source project of Multiconf ;-)
On Wed, Dec 3, 2014 at 2:47 PM, Anatole Tresch <[email protected]> wrote: > Hmm. Pros abd cons: pro format is important, cons: i tried to minimize the > api: reader:something -> the reader can be implemented in any way. The > implementation can decide, if (explit) formats are supported, eg: > reader:[format]foo. Therefore I moved the format part to the implementation > completely... > > Other opinions? > Werner Keil <[email protected]> schrieb am Mi., 3. Dez. 2014 um 14:35: > > > What would "reader" or "format" have to to here in a fromPath() method? > > That's more a "reader" or "loader" thing, some may call it "parsing" but > > I'd say that only makes sense if you have a relatively small string, not > > broader source. > > > > It may be a little bit simpler given the input format is only W3C DDR > > compliant XML data, but looking at recently graduated DeviceMap, the > > ".next" Java client offers a variety of "resource loaders" either from > > within an archive, a URL or as file in a file system: > > http://svn.apache.org/repos/asf/devicemap/trunk/devicemap/ > > java/classifier/src/main/java/org/apache/devicemap/loader/ > > > > Reporting and output or "formatting" would be something different IMHO, > not > > to be mixed with loader or reader. > > > > Werner > > > > On Wed, Dec 3, 2014 at 2:24 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > > > 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 > > > >> > >> > > > > >> > >> > > > >> > > > > >> > > > > > >
