Hi Lukasz It’s a good idea for system/custom properties. It’s similar/extend of the custom.system.properties we already have in system.properties right ?
For json/cfg files, it’s not necessary as we can already override with system properties or env variables (useful with docker) IMHO. Regards JB > Le 11 juin 2021 à 10:34, Łukasz Dywicki <l...@code-house.org> a écrit : > > Hey all, > > I recently been going over few Karaf assemblies I created in past years > and I realized that in many cases I had to copy entire configuration > shipped by Karaf distribution in order to include a new config in > bootstrap process. > Quite often my requirements were quite small, yet I had to create two > files and take care of updates of distro shipped file in order to keep > assembly well behaving. > > Looking at base resources: > https://github.com/apache/karaf/tree/karaf-4.3.2/assemblies/features/base/src/main/filtered-resources/resources/etc > > If distro builder wants to override or extend any of properties defined > in these he needs to copy a whole file. While it is not a problem for > custom properties it is a burden for jre and system properties which > vary between releases. > > This week I attempted a bit simplified approach which can be summarized as: > 1) Define default ${optionals} dedicated to overrides, ie. ${optionals} > = custom.config.properties > 2) Update each interesting system property to contain an placeholder > with fallback. For example: > org.osgi.framework.system.packages=\ > ... \ > org.apache.karaf.info;version="4.2.9",\ > ${jre-${java.specification.version}}, \ > ${custom.org.osgi.framework.system.packages:-} > > With this approach user who needs to add an extra import or export for > his environment needs to do just one thing. Create a > "custom.config.properties" file with a single line: > custom.org.osgi.framework.system.packages=jdk.internal.math > > Packager work related to overrides of distro files is completely > removed. More over this also leaves end user free of the need to fight > ordering of dependencies in maven poms to shade Karaf defaults. > > While above is quite handy there is a security consideration to be made. > First of all, creation of an optional file might simplify process of > affecting existing Karaf installations through easier injection of > additional options. I believe that proper file and folder permissions > should prevent that, however it must be noted that distro will have more > flexible configuration injection with all pros and cons. > > Best, > Łukasz > -- > Integrate software (Code-House) & hardware (ConnectorIO) > http://code-house.org > http://connectorio.com
