Hi Oliver it is just the Resource abstraction that actually makes sense (adds an abstraction from if its read remotedly or from whatever source). Just do it the straight forward way as of now. We still can adapt things, later. And I personally need more time to come up with a more easy and lean proposal, especially one that is small and parts of it may even go out into an extensopm...
Anatole 2015-01-02 17:30 GMT+01:00 Oliver B. Fischer <[email protected]>: > Hi Anatole, > > sounds reasonable but what is left for the PropertySource? I would like to > have a distinction between the physical access to a resource (file, > database, ...), the parsing of the format (ConfigFormatReader???) and > storage of the found properties (PropertySource). > > WDYT? > > Oliver > > > Am 02.01.15 um 15:21 schrieb Anatole Tresch: > > Hi Oliver >> >> I have adapted the format interface and implemented (but not committed) >> PropertyFileFormat and PropertyXmlFileFormat. Basically a ConfigFileFormat >> is only a mapping from resource to a collection of PropertySource, nothing >> more is left. The interface I would like to use to combine the config >> format with a PropertySourceProvider builder. >> One things is that depending on the file location you probably will apply >> a >> default ordinal other than the global default. So I suggest that, you also >> can pass this default ordinal to your resource reader impls. >> >> Makes that sense? >> >> Anatole >> >> >> 2015-01-02 15:14 GMT+01:00 Oliver B. Fischer <[email protected]>: >> >> Before touching a single line of code for the JSON and YAML support I >>> would like to discuss with you how we can et from the physical resource >>> to >>> the property source. In the code by Anatole there was a distinction >>> between >>> ConfigFormat (JSON, property files,...) and the PropertySource itself. >>> >>> So is it sufficient enough to have a constructor >>> JSONPropertySource([File| >>> Inputstream])? >>> >>> For the first steps it would be enough but how to handle this later? >>> >>> WDYT? >>> >>> Oliver >>> >>> -- >>> 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 >>> >>> >>> >> > -- > 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 > > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
