Hi all I remember a long discussion on where configuration should be and where not. In short: - Configuration that is more related to you concrete application internals, especially the one that is not deployment dependent, should be packaged with your code. It has a strong cohesion with the code and there is no need admins should have control over it. - Configuration that is only deployment dependent and no reasonable defaults are present should only provided externally. The application should check its availabiolity during startup and ceed to function if parts are missing (deployment error). - Configuration that has resonable defaults, and may be tailored depedent the runtime environment, should have defaults in the classpath, but being overridable from external sources. - There always might be exception that require overriding things (especially thrid party integration), so the possibility of overriding things by applications is always a good way and gives developers flexibility. On the down side, there might be security concerns, that app devs should not be able to change everything (in a pragrammtic approach, leave SecurityManager off as of now).
How configuration is added from external depends on the concrete target runtime. Could be a simple external folder on the file system (which could be a distributed one, NFS share or whatever), or be stored and managed more explicitly, e.g. in database (SQL, or nosql doesn't matter). So thinking all is always external or files only is a chosen approach, it is by far not the only valid one. It doesn't depend either of the size of your company, it more driven by the configuration requirements and the functionality of the tool chain around it... Cheers, Anatole 2015-01-07 10:55 GMT+01:00 Mark Struberg <[email protected]>: > only the default databaseIP/url should be part of the 'internal' config. > Or none at all! > > You can still override this configuration via -D, env and probably we also > come back to add JNDI by default... All those ConfigSources are 'external' > to your application. > > > LieGrue, > strub > > > > > > > On Wednesday, 7 January 2015, 10:48, Romain Manni-Bucau < > [email protected]> wrote: > > >T hink you didnt get it, you packaged the database IP, it changes and > > you dont repackage reading from inside the app? Give me the formula :p > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > > > 2015-01-07 10:42 GMT+01:00 Mark Struberg <[email protected]>: > >> no it's not useless because ALL the property files with this name will > > get picked up. And the programmer is in full charge! > >> And no, there is no code change required for the case you mentioned. > >> > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >>> On Wednesday, 7 January 2015, 10:30, Romain Manni-Bucau > > <[email protected]> wrote: > >>> > sure but classpath config = hardcoded config so it is quite > > useless. > >>> Config makes sense when it is outside the app. All bundled config will > >>> imply to modify the app/package if the environment changes -> this > > is > >>> code not config > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> > >>> 2015-01-07 10:27 GMT+01:00 Mark Struberg <[email protected]>: > >>>> 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 > >>>>>>> > >>>>> > >>> > > > -- *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*
