I agree this easily can cause ordering issues. In the best case these can cause components to be started with wrong configuration first and with the correct one later. This can at least cause some error messages but might also cause more serious issues.
For a cloud deployment were config is mainly static I hope we can provide a solution that avoids restarts in most cases. Env variable substitution could be a core feature of the configurator as it is very common. Christian Am Di., 21. Aug. 2018 um 10:22 Uhr schrieb Peter Kriens via osgi-dev < [email protected]>: > On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev <[email protected]> > wrote: > Just another vote in favour of the ConfigurationPlugin model - you can use > this to post-process configurations wherever they come from (meaning it > isn’t tied to the Configurer or Configurator). > A configuration plugin that does this sort of work is easy to write, and > if using DS could be done in a lot less than 100 LoC. It can also look at > things other than environment variables if you want, and if/else logic is > much easier to write/maintain in Java code than it is in macros in a JSON > file! > > > It is only easier after you sold the ordering problem of the > > * Configurator, > * Configuration bundle, and > * Configuration plugin bundle … > > It also adds quite a bit of complexity by: > > * Separating the rules from the actual configuration, and > * Adding extra bundles. > > This additional complexity is only worth it if you can reuse the rules in > many different places. Hmm. Maybe a configuration plugin with a macro > processor? :-) > > Peter Kriens > > > Best Regards, > > Tim > > On 20 Aug 2018, at 17:08, Mark Hoffmann via osgi-dev < > [email protected]> wrote: > > Hi all, > > Carsten Ziegeler pointed us to the Configuration Plugin Services, that are > part of the ConfigurationAdmin specification. Together with the > Configurator specification, it could be possible to do that substitution in > such an plugin. > > Regards, > > Mark > > Am 20.08.2018 um 17:56 schrieb Christian Schneider via osgi-dev: > > I think this would be a good extension to the configurator to also allow > env variable replacement. > Actually I hoped it would already do this... > WDYT? > > Christian > > Am Mo., 20. Aug. 2018 um 17:05 Uhr schrieb Peter Kriens via osgi-dev < > [email protected]>: > >> Are you using v2Archive enRoute or the new one? >> >> The v2Archive OSGi enRoute has the simple Configurer (the predecessor of >> the OSGi R7 Configurator but with, according to some, a better name :-). It >> runs things through the macro processor you could therefore use environment >> variables to make the difference. >> >> E.g. ${env;XUZ} in the json files. Since it also supports ${if} you can >> eat your heart out! You can set environment variables in docker with -e in >> the command line when you start the container. You can also use @{ instead >> of ${ to not run afoul of the bnd processing that can happen at build time. >> I.e. the Configurer replaces all @{…} with ${…}. >> >> If you are using the new R7 Configurator then you are on your own ... >> >> Kind regards, >> >> Peter Kriens >> >> >> >> >> > On 18 Aug 2018, at 18:51, Randy Leonard via osgi-dev < >> [email protected]> wrote: >> > >> > To all: >> > >> > We are at the point where we are deploying our OSGI enRoute >> applications via Docker. >> > >> > - A key sticking point is the syntax for embedding environment >> variables within our configuration.json files. >> > - For example, a developer would set a hostName to ‘localhost’ for >> development, but this same environment variable would be different for QA, >> UAT, and Production environments >> > - I presume this is the best way of allowing the same container to be >> deployed in different environments without modification? >> > - Suggestions and/or examples are appreciated. >> > >> > >> > >> > Thanks, >> > Randy Leonard >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com > > > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > -- > Mark Hoffmann > M.A. Dipl.-Betriebswirt (FH) > Geschäftsführer > > Tel: +49 3641 384 910 0 > Mobil: +49 175 701 2201 > E-Mail: [email protected] > Web: www.datainmotion.de > > Data In Motion Consulting GmbH > Kahlaische Straße 4 > 07745 Jena > > Geschäftsführer > Mark Hoffmann > Jürgen Albert > > Jena HRB 513025 > Steuernummer 162/107/05779 > USt-Id DE310002614 > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
