:) that's what we all say and we left the original thread
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-08 8:50 GMT+01:00 Oliver B. Fischer <[email protected]>: > Hi all, > > I agree with you Anatole. There is no standard way there to place your > configuration data. And we must not restrict the user in that ways that we > decide how to solve this problem. > > From my point of view we must provide a framework which helps the user to > solve his problem. And not the other way around. > > Olive > > Am 07.01.15 um 11:14 schrieb Anatole Tresch: > >> 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 >>>>>>>>>> >> >> > > -- > 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 >
