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