Re: [Context Aware Configs] Merging?

On Thu, Aug 18, 2016 at 11:52 AM, Stefan Seifert wrote: > ...perhaps we find a way to support both ways with the pluggable architecture > i've in mind and > that in good parts is already in use in wcm.io - activate the property-level > merging osgi service or > bundle if

RE: [Context Aware Configs] Merging?

>So far, no one needed it, as the implementation which is used today does >not support it. well, depends which implementation is referenced - in the wcm.io Config property-level merging for parameter inheritance is supported. i agree with the arguments from justin and georg, and see more

Re: [Context Aware Configs] Merging?

>> * Puppet (not too sure about the others) is not exactly great at dealing >> with xml files >> * FileVault [1] is only available in Java, if you want to create proper >> packages with it you have to call out to java from other languages > > Packages are zip files with a defined structure and

Re: [Context Aware Configs] Merging?

On Mon, Aug 1, 2016 at 7:24 AM Robert Munteanu wrote: > On Mon, 2016-08-01 at 11:34 +0100, Ian Boston wrote: > > Hi, > > > > On 1 August 2016 at 11:02, Carsten Ziegeler > > wrote: > > > > > > > > Well, I think you're misinterpreting my comments - I

Re: [Context Aware Configs] Merging?

Hi, On Sun, Jul 31, 2016 at 7:07 AM Carsten Ziegeler wrote: > > Allow me to disagree. This lack of merging is actually one of the key > pain > > points I have with OSGi ConfigAdmin and I would really love to see it > > accommodated here. The problem with not merging is

Re: [Context Aware Configs] Merging?

Hi, On 2 August 2016 at 10:30, Georg Henzler wrote: > On 2016-08-01 13:29, Konrad Windszus wrote: > >> Can't we just use the resource merger approach for merging configs >> ( >> http://sling.staging.apache.org/documentation/bundles/resource-merger.html >> < >>

Re: [Context Aware Configs] Merging?

On 2016-08-01 13:29, Konrad Windszus wrote: Can't we just use the resource merger approach for merging configs (http://sling.staging.apache.org/documentation/bundles/resource-merger.html )? There probably needs to be a

Re: [Context Aware Configs] Merging?

Can't we just use the resource merger approach for merging configs (http://sling.staging.apache.org/documentation/bundles/resource-merger.html )? There probably needs to be a dedicated resource picker for configurations,

Re: [Context Aware Configs] Merging?

On Mon, 2016-08-01 at 11:34 +0100, Ian Boston wrote: > Hi, > > On 1 August 2016 at 11:02, Carsten Ziegeler > wrote: > > > > > Well, I think you're misinterpreting my comments - I never said > > that it > > will require a special tooling - I said it would be insane to edit

Re: [Context Aware Configs] Merging?

Hi, On 1 August 2016 at 11:02, Carsten Ziegeler wrote: > Well, I think you're misinterpreting my comments - I never said that it > will require a special tooling - I said it would be insane to edit a > complex setup by editing nodes in the repository. > I was, apologies

Re: [Context Aware Configs] Merging?

Well, I think you're misinterpreting my comments - I never said that it will require a special tooling - I said it would be insane to edit a complex setup by editing nodes in the repository. Clearly with devops automation you have some tooling already in place which is using text files and does

Re: [Context Aware Configs] Merging?

Hi, I think it must be possible to configure a Sling/AEM instance without using specific Sling/AEM tooling to create and manage the source configuration. The reason I say this is almost all serious deployments use some form of DevOps automation ranging from Puppet/Chef/AWS etc through to

Re: [Context Aware Configs] Merging?

> Hi everyone, > > I personally see a tooling based approach complicated due to the ownership > scenarios. Let's assume two scenarios, configuration A and configuration B inherits from A. Now, if we support merging, someone is allowed to change A, adds a new property and this automatically

Re: [Context Aware Configs] Merging?

Hi everyone, I personally see a tooling based approach complicated due to the ownership scenarios. We are talking about context aware configuration that typically would be applied by some runtime user that might have limited write access (just for a specific context). The assumption that who

Re: [Context Aware Configs] Merging?

>> ... if you have merging (or inheritance) then you change the >> attribute of a parent and this influences all childs and you >> have no idea what happens there... > > We can create a felix console plugin that shows for a given > context path and config name the value of the property and the >

Re: [Context Aware Configs] Merging?

... if you have merging (or inheritance) then you change the attribute of a parent and this influences all childs and you have no idea what happens there... We can create a felix console plugin that shows for a given context path and config name the value of the property and the path from where

Re: [Context Aware Configs] Merging?

> Allow me to disagree. This lack of merging is actually one of the key pain > points I have with OSGi ConfigAdmin and I would really love to see it > accommodated here. The problem with not merging is that it results in a lot > of error-prone duplication and you can easily get into a state where

Re: [Context Aware Configs] Merging?

+1 for me too, one of the real life examples that I have in most of my projects is that you have a site /content/mysite and you have some languages like /content/mysite/en and /content/mysite/fr It would be nice to put all your global mysite configs on /content/mysite, but still have the

Re: [Context Aware Configs] Merging?

A big +1 from my side to support merging (all the way down to property level) from the very first release. IMHO it's not that hard to implement and it saves a lot of frustration downstream. On 2016-07-29 17:10, Justin Edelson wrote: Allow me to disagree. This lack of merging is actually one of

Re: [Context Aware Configs] Merging?

Hi, Properties should not be merged, as that will produce undesirable side effects, however some things need to be merged. Having attempted to write documentation I found it easiest to describe in terms of json documents. Using the examples in

Re: [Context Aware Configs] Merging?

Allow me to disagree. This lack of merging is actually one of the key pain points I have with OSGi ConfigAdmin and I would really love to see it accommodated here. The problem with not merging is that it results in a lot of error-prone duplication and you can easily get into a state where new

Re: [Context Aware Configs] Merging?

Not having any specific opinion here but just for an example. Maven allows merging of config [1] but that requires parent config to declare/allow the child to merge there config. So merging "intention" is explicitly mentioned. So if we plan to support this sometime later (with a big if!) then

Re: [Context Aware Configs] Merging?

> Hi, > Properties should not be merged, as that will produce undesirable side > effects, however some things need to be merged. > > Having attempted to write documentation I found it easiest to describe in > terms of json documents. > Using the examples in >

Re: [Context Aware Configs] Merging?

Hi, On Fri, Jul 29, 2016 at 4:11 PM, Carsten Ziegeler wrote: > ...I personally think we should *not* support any merging because as soon > as you support merging you will need additional ways of not merging > properties etc etc Combining configs sounds a lot like

[Context Aware Configs] Merging?

Hi, looking at various documentations on the different approaches and the implementations, there seem to be totally different opinions about if merging of resources (and therefore resources) should be done. For this topic, let's not discuss names or how the resolving really should work, let's