was the case in one of my previous company with a kind of stage in the file naming (foo-prod.properties more or less). It is awesome...but one day some machines was migrated and all apps needed to change. I understand the default idea - even if I'm not convinced why it should be in file cause it risks to be out of sync with the code - but for all other settings there is always a point in real life where it brings enough drawbacks to not do it IMO. But that's on bad vs good practises IMO so not sure we need to discuss it a lot. A solution doesn't need to prevent user to do what he wants even if it is bad, doc can help BTW.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-08 8:46 GMT+01:00 Oliver B. Fischer <[email protected]>: > We have currently all configuration files of our applications below > /config/<service>/etc located. ;-) > > Am 07.01.15 um 10:27 schrieb Mark Struberg: > >> we can do both. But how do you ship your application and what is always >> there? Exactly, the ClassPath. >> >> >> LieGrue, >> strub >> >> >> >> >> >>> On Wednesday, 7 January 2015, 9:49, Romain Manni-Bucau >>> <[email protected]> wrote: >>>> >>>> @Mark: read it from file system and not jars :p >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> >>> 2015-01-07 9:29 GMT+01:00 Mark Struberg <[email protected]>: >>>> >>>> Do you know the locations of your JSON files or do you need anything >>>> which >>> >>> is not available during the app boot (e.g. CDI or EJB)? In that case you >>> don't even need to touch the ConfigurationContext. >>>> >>>> >>>> Simply create a new class >>>> >>>> public class MyAppJsonPropertySourceProvider implements >>> >>> PropertySourceProvider { >>>> >>>> List<PropertySource> jsonSources = new ArrayList<>(); >>>> >>>> iterator over >>> >>> classLoader.getResources("myownjsonconfigfile.json") { >>>> >>>> jsonSources.add(new JSONPropertySource(jsonFileUrl); >>>> >>>> } >>>> return jsonSources; >>>> } >>>> >>>> and then create a file >>>> META-INF/services/org.apache.tamaya.spi.PropertySourceProvider >>>> >>>> >>>> >>>> and write your fully qualified MyAppJsonPropertySourceProvider class >>>> name >>> >>> into it. >>>> >>>> >>>> That's it. >>>> >>>> But to be honest. The JSON configuration is nice but what benefit does >>>> it >>> >>> have over a property file which you get out of the box? >>>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>>> On Wednesday, 7 January 2015, 9:07, Oliver B. Fischer >>> >>> <[email protected]> wrote: >>>>> >>>>> > Because I am unable to see how to turn this >>>>> >>>>> JSONPropertySource source =newJSONPropertySource(...); >>>>> >>>>> ConfigurationContext context = ConfigurationContext.context(); >>>>> >>>>> context.addPropertySources(source); >>>>> >>>>> >>>>> in a Configuration... >>>>> >>>>> Oliver >>>>> >>>>> Am 07.01.15 um 08:53 schrieb Romain Manni-Bucau: >>>>>> >>>>>> Did I miss the reason in this thread or why a provider doesnt >>> >>> solve it? >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2015-01-07 8:49 GMT+01:00 Oliver B. Fischer >>>>> >>>>> <[email protected]>: >>>>>>> >>>>>>> This is the scenario for huge classic enterprises. There are >>> >>> many >>>>> >>>>> companies >>>>>>> >>>>>>> working in a more agile fashion there with not such and strict >>>>> >>>>> destinction >>>>>>> >>>>>>> between these roles. And I am not willing to leave them >>> >>> behind. >>>>>>> >>>>>>> Oliver >>>>>>> >>>>>>> Am 07.01.15 um 00:41 schrieb Anatole Tresch: >>>>>>> >>>>>>>> No. Configuratipn is the api for end users. Users that >>> >>> provide app >>>>> >>>>> config >>>>>>>> >>>>>>>> and consume it are not the same than the one that define >>> >>> how >>>>> >>>>> apps/solutions >>>>>>>> >>>>>>>> have to be configured. The ladder may be lead engineers , >>> >>> or in >>>>> >>>>> case you >>>>>>>> >>>>>>>> have a platform the platform and technical srchitects... >>>>>>>> >>>>>>>> - >>>>>>>> Anatole Tresch >>>>>>>> Glärnischweg 10 >>>>>>>> 8620 Wetzikon >>>>>>>> Tel +41 (43) 317 05 30 >>>>>>>> - >>>>>>>> Send from Mobile >>>>>>>> >>>>>>>>> Am 06.01.2015 um 23:58 schrieb "Oliver B. >>> >>> Fischer" >>>>>>>>> >>>>>>>>> <[email protected]>: >>>>>>>>> >>>>>>>>> I think a lot of user will use ConfigurationContext to >>>>> >>>>> configure their >>>>>>>>> >>>>>>>>> configuration system. I think it is easier to put some >>> >>> files >>>>> >>>>> into the >>>>>>>>> >>>>>>>>> filesystem and to read this files then to deal with >>> >>> the SPI >>>>> >>>>> stuff. >>>>>>>>> >>>>>>>>> Sometimes I have the impression that many of us have a >>> >>> very >>>>> >>>>> biased view >>>>>>>>> >>>>>>>>> on configuration by coming from a Java EE environment. >>> >>> This is >>>>> >>>>> ok and I miss >>>>>>>>> >>>>>>>>> my GlassFish sometimes but think of dumb programmer >>> >>> who wants >>>>> >>>>> to read a file >>>>>>>>> >>>>>>>>> simply from /etc/service/config.ext and override these >>> >>> defaults >>>>> >>>>> with >>>>>>>>> >>>>>>>>> ~/.config.ext and so on. >>>>>>>>> >>>>>>>>> Oliver >>>>>>>>> >>>>>>>>>> Am 06.01.15 um 23:47 schrieb Reinhard Sandtner: >>>>>>>>>> my first idea was to add the method getContext() >>> >>> to >>>>> >>>>> Configuration but i >>>>>>>>>> >>>>>>>>>> think if someone is able to use the SPI, they can >>> >>> do it on >>>>> >>>>> their own. >>>>>>>>>> >>>>>>>>>> i think a 'normal‘ user should not see the >>>>> >>>>> configurationContext at all >>>>>>>>>> >>>>>>>>>> lg >>>>>>>>>> reini >>>>>>>>>> >>>>>>>>>>> Am 06.01.2015 um 23:43 schrieb Oliver B. >>> >>> Fischer >>>>>>>>>>> >>>>>>>>>>> <[email protected]>: >>>>>>>>>>> >>>>>>>>>>> Guys, I missed somehow how to get a >>> >>> Configuration from >>>>> >>>>> the >>>>>>>>>>> >>>>>>>>>>> ConfigurationContext. >>>>>>>>>>> >>>>>>>>>>> BTW: I will add this method to >>> >>> ConfigurationContext: >>>>>>>>>>> >>>>>>>>>>> public static ConfigurationContext >>> >>> current(){ >>>>>>>>>>> >>>>>>>>>>> return >>>>>>>>>>> >>> >>> ServiceContext.getInstance().getService(ConfigurationContext.class).get(); >>>>>>>>>>> >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> > > -- > 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 >
