date:20180821

Re: [osgi-dev] Disposing component instances

2018-08-21 Thread Paul F Fraser via osgi-dev


On 22/08/2018 5:40 AM, Paul F Fraser via osgi-dev wrote:

On 21/08/2018 10:00 PM, Tim Ward via osgi-dev wrote:
Have you looked at what the OSC project does? It uses Vaadin, and uses the ViewProvider interface 
to provide view instances. These automatically have a detach listener added on creation so that 
they get correctly disposed when their parent container is closed.


See 
https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L60-L67 for 
details.


Tim


Hi Tim,
The R7 Spec 112.3.6 states that "SCR must unget any unreleased service objects" and it sounds to 
me that the system is supposed to clean itself up.

What am I missing.

What am I missing?

Apart from a question mark.. that is.


Paul Fraser
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev



___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Disposing component instances

2018-08-21 Thread Paul F Fraser via osgi-dev


On 21/08/2018 10:00 PM, Tim Ward via osgi-dev wrote:
Have you looked at what the OSC project does? It uses Vaadin, and uses the ViewProvider interface 
to provide view instances. These automatically have a detach listener added on creation so that 
they get correctly disposed when their parent container is closed.


See 
https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L60-L67 for 
details.


Tim


Hi Tim,
The R7 Spec 112.3.6 states that "SCR must unget any unreleased service objects" and it sounds to me 
that the system is supposed to clean itself up.

What am I missing.

Paul Fraser
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Docker configuration via environment variables

2018-08-21 Thread Peter Kriens via osgi-dev

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  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 
> mailto:osgi-dev@mail.osgi.org>>:
>> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev > > 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 
>>> mailto:osgi-dev@mail.osgi.org>> 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 
 mailto:osgi-dev@mail.osgi.org>>:
 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 
 > mailto:osgi-dev@mail.osgi.org>> 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
 > osgi-dev@mail.osgi.org 
 > https://mail.osgi.org/mailman/listinfo/osgi-dev 
 > 
 
 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org

Re: [osgi-dev] Disposing component instances

2018-08-21 Thread Alain Picard via osgi-dev

Tim,

I didn't know anything about OSC, so hadn't looked but we use ZK which is
quite similar to Vaadin, so the use case is pretty similar and this
provides a nice point of reference.

Thanks
Alain


On Tue, Aug 21, 2018 at 8:00 AM Tim Ward  wrote:

> Have you looked at what the OSC project does? It uses Vaadin, and uses the
> ViewProvider interface to provide view instances. These automatically have
> a detach listener added on creation so that they get correctly disposed
> when their parent container is closed.
>
> See
> https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L60-L67
>  for
> details.
>
> Tim
>
> On 21 Aug 2018, at 09:56, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> When using factory components, you get a ComponentInstance and you should
> dispose once done. For services with prototype scope, you get
> ComponentServiceObjects from which you need to ungetService after use.
>
> I have some cases where I am creating some UI Widgets and where I don't
> have a well defined lifecycle that my class controls. It is expected to
> hand over a widget and the widget will be "disposed" when necessary. The
> widget can add actions when it is "disposed" or a listener can be added to
> watch for such events with the UI framework.
>
> What is the best way to handle those and is either factory component or
> CSO better that the other, in this case and others? I was thinking that I
> might implement a factory for managed widgets that keeps a map of provided
> widgets and registers for events of disposed widgets and cleans up at that
> time, but feels like an added moving part.
>
> Alain
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Disposing component instances

2018-08-21 Thread Tim Ward via osgi-dev

Have you looked at what the OSC project does? It uses Vaadin, and uses the 
ViewProvider interface to provide view instances. These automatically have a 
detach listener added on creation so that they get correctly disposed when 
their parent container is closed. 

See 
https://github.com/opensecuritycontroller/osc-core/blob/4441c96fe49e4b11ce6f380a440367912190a246/osc-ui/src/main/java/org/osc/core/broker/view/OSCViewProvider.java#L60-L67
 

 for details.

Tim

> On 21 Aug 2018, at 09:56, Alain Picard via osgi-dev  
> wrote:
> 
> When using factory components, you get a ComponentInstance and you should 
> dispose once done. For services with prototype scope, you get 
> ComponentServiceObjects from which you need to ungetService after use.
> 
> I have some cases where I am creating some UI Widgets and where I don't have 
> a well defined lifecycle that my class controls. It is expected to hand over 
> a widget and the widget will be "disposed" when necessary. The widget can add 
> actions when it is "disposed" or a listener can be added to watch for such 
> events with the UI framework.
> 
> What is the best way to handle those and is either factory component or CSO 
> better that the other, in this case and others? I was thinking that I might 
> implement a factory for managed widgets that keeps a map of provided widgets 
> and registers for events of disposed widgets and cleans up at that time, but 
> feels like an added moving part.
> 
> Alain 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Docker configuration via environment variables

2018-08-21 Thread Christian Schneider via osgi-dev

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 <
osgi-dev@mail.osgi.org>:

> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev 
> 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 <
> osgi-dev@mail.osgi.org> 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 <
> osgi-dev@mail.osgi.org>:
>
>> 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 <
>> osgi-dev@mail.osgi.org> 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
>> > osgi-dev@mail.osgi.org
>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>
>
> ___
> OSGi Developer Mail 
> listosgi-...@mail.osgi.orghttps://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: m.hoffm...@data-in-motion.biz
> 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

[osgi-dev] Disposing component instances

2018-08-21 Thread Alain Picard via osgi-dev

When using factory components, you get a ComponentInstance and you should
dispose once done. For services with prototype scope, you get
ComponentServiceObjects from which you need to ungetService after use.

I have some cases where I am creating some UI Widgets and where I don't
have a well defined lifecycle that my class controls. It is expected to
hand over a widget and the widget will be "disposed" when necessary. The
widget can add actions when it is "disposed" or a listener can be added to
watch for such events with the UI framework.

What is the best way to handle those and is either factory component or CSO
better that the other, in this case and others? I was thinking that I might
implement a factory for managed widgets that keeps a map of provided
widgets and registers for events of disposed widgets and cleans up at that
time, but feels like an added moving part.

Alain
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Docker configuration via environment variables

2018-08-21 Thread Tim Ward via osgi-dev

I’m not sure where you think the ordering problem is between the Configurator, 
the Configuration Bundle and the bundle being configured…

As for the Configuration Plugin, I would expect a ConfigurationPlugin like this 
to be a feature of the launcher, being the one part of the system with at least 
some reason to couple to the environment.

Best Regards,

Tim

> On 21 Aug 2018, at 09:21, Peter Kriens  wrote:
> 
>> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev > > 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 
>>> mailto:osgi-dev@mail.osgi.org>> 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 
 mailto:osgi-dev@mail.osgi.org>>:
 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 
 > mailto:osgi-dev@mail.osgi.org>> 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
 > osgi-dev@mail.osgi.org 
 > https://mail.osgi.org/mailman/listinfo/osgi-dev 
 > 
 
 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org 
 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
 osgi-dev@mail.osgi.org

Re: [osgi-dev] Docker configuration via environment variables

2018-08-21 Thread Peter Kriens via osgi-dev

> On 21 Aug 2018, at 10:11, Tim Ward via osgi-dev  
> 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 > > 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 
>>> mailto:osgi-dev@mail.osgi.org>>:
>>> 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 
>>> > mailto:osgi-dev@mail.osgi.org>> 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
>>> > osgi-dev@mail.osgi.org 
>>> > https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> > 
>>> 
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org 
>>> 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
>>> osgi-dev@mail.osgi.org 
>>> 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: m.hoffm...@data-in-motion.biz 
>> 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
>> 
>> 
>>

Re: [osgi-dev] Docker configuration via environment variables

2018-08-21 Thread Tim Ward via osgi-dev

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!

Best Regards,

Tim

> On 20 Aug 2018, at 17:08, Mark Hoffmann via osgi-dev  
> 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 
>> mailto:osgi-dev@mail.osgi.org>>:
>> 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 
>> > mailto:osgi-dev@mail.osgi.org>> 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
>> > osgi-dev@mail.osgi.org 
>> > https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> > 
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org 
>> 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
>> osgi-dev@mail.osgi.org 
>> 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: m.hoffm...@data-in-motion.biz 
> 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
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Disposing component instances

Re: [osgi-dev] Disposing component instances

Re: [osgi-dev] Docker configuration via environment variables

Re: [osgi-dev] Disposing component instances

Re: [osgi-dev] Disposing component instances

Re: [osgi-dev] Docker configuration via environment variables

[osgi-dev] Disposing component instances

Re: [osgi-dev] Docker configuration via environment variables

Re: [osgi-dev] Docker configuration via environment variables

Re: [osgi-dev] Docker configuration via environment variables

10 matches

Site Navigation

Mail list logo

Footer information