For additional context, this was due to #32724 - for most mapFrom operations we were using a distinct input value, such that the general transformer did not apply. So the change created a separate mapFrom transformer. It also seemed more complicated to chain the transformations - apply mapFrom first, then the general one, so they were left separate.

An alternative to this change is to automatically use the parent transformer when it is present as the mapFrom transformer when it is not specified.

@mabartos there are two options to prevent the redundency in this situation - it will come up again if we have any other base property with a tranformation.

1. Change

   keycloak/quarkus/runtime/src/main/java/org/keycloak/quarkus/runtime/configuration/mappers/PropertyMapper.java

   Line 261 in 2b44c56

   var theMapper = parentValue ? this.parentMapper : this.mapper;

   to var theMapper = parentValue && this.parentMapper != null ? this.parentMapper : this.mapper; - that is if we don't specify a parentMapper, then fall through to the tranformer.

2. Do cascading application of transforms - apply the parentMapper first, then apply the regular transform. While this is more logical, it wasn't desirable for specifying the cache config file - but ultimately won't currently make a difference.

An alternative to this change is to automatically use the parent transformer when it is present as the mapFrom transformer when it is not specified.

@shawkins Thanks. Make sense to me to use the parent mapper if the mapFrom mapper is not specified. It seems to me it's not so invasive change, and we can backport it without risking the mapping will break apart.

Btw. we would need to have a diagram on how the transformation works for prop mappers soon 😄

Btw. we would need to have a diagram on how the transformation works for prop mappers soon 😄

Right, it's not always clear how the map from, transformer, and default play together.