Hi, On 2 August 2016 at 10:30, Georg Henzler <[email protected]> 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 >> < >> http://sling.staging.apache.org/documentation/bundles/resource-merger.html >> >)? >> There probably needs to be a dedicated resource picker for >> configurations, because neither the search path approach nor the >> resource super type approach is applicable for configurations. >> > > Sounds like a good match, I could imagine that way we could implement > merged configs fairly easily! > > Clearly with devops automation you have some tooling already in place >>> which is using text files and does something to start AEM, so you can >>> add the stuff there - or - the configuration are content packages after >>> all, so if the automation supports content packages in some form, you're >>> done. >>> >>> >> Agreed. >> > > DevOps automation is nice, but for generating CRX packages with xml config > files it's not a great match: > * 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 some required files. If you have a template, a few lines of bash (cp -r, sed, zip) will create a package containing OSGi configs. This works well in Kubernetes within Docker images. (btw, without a package and its version number, the OSGIPackageInstaller doesnt install replacement config files) > * Not having a standard approach makes every project implement their > homegrown solution (and waste budget where it could really be standard). > I've have seen a few awkward solutions for generating OSGi configs > * Alternatively (and this is what I've seen happening the most for OSGi > configs), people just accept the fact that they have to duplicate > configuration sets and then run into all the frustration Justin described > earlier > > So I'm still in big favour of having a runtime solution. > +1. Will OSGi configs be context aware or do they only make sense in a Global context (overridden by /libs /apps )? I can see how a Factory might generate multiple configs, but OSGi components are shared and survive outside most Request or Job contexts. Only where a component is actually created and dies on a thread with context will context aware OSGi configurations make sense... or am I missing something ? Best Regards Ian > > Best Regards > Georg > > [1] > http://jackrabbit.apache.org/filevault/ >
