Indeed It is the same mechanism I would love to see employed in mentioned places.
The way how custom.system.properties works is great. Combined with property resolver and fallbacks we can save peoples time in synchronizing (jre|custom).properties. I will try to book some time for this to register JIRA and cook an PR in coming weeks (please don't be surprised if it will turn into a month). Best, Łukasz -- Integrate software (Code-House) & hardware (ConnectorIO) http://code-house.org http://connectorio.com On 11.06.2021 12:25, Jean-Baptiste Onofre wrote: > 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 >
