here some samples i'd expect: - http:properties:http://.... - https:xml:https://.... - classpath:yaml:/foo/bar.yml - custom:json:myapp # and use a company convention like /foo/bar/app/myapp.json
etc... Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-03 14:35 GMT+01:00 Werner Keil <[email protected]>: > 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 >> >> > >> > >> >> > >> >> >> > >> >> >>
