I think you get the point …

A simple macro processor is ~10k and would go a long way to address the far 
majority of the common requirements. And there is more than 6 years experience 
with the model already :-)

Kind regards,

        Peter Kriens

> On 21 Aug 2018, at 12:09, Christian Schneider <[email protected]> wrote:
> 
> 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] <mailto:[email protected]>>:
>> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev <[email protected] 
>> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>
>>>> > https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>>> > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>> 
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> [email protected] <mailto:[email protected]>
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>> 
>>>> -- 
>>>> -- 
>>>> Christian Schneider
>>>> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>>>> 
>>>> Computer Scientist
>>>> http://www.adobe.com <http://www.adobe.com/>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> [email protected] <mailto:[email protected]>
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>>> <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] <mailto:[email protected]>
>>> Web: www.datainmotion.de <http://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] <mailto:[email protected]>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev 
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
> 
> Computer Scientist
> http://www.adobe.com <http://www.adobe.com/>
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to