Looks for a property based first on the applicaionId and then the tenantId and then with no
discrimination. Assuming a properties prefix of 'broadleaf.tax.provider.simple', if you pass
in a fieldName of 'foo', an applicationId of 'abc', and a tenantId of '123, this will search
for the following, in order:
- broadleaf.tax.provider.simple.application.abc.foo
- broadleaf.tax.provider.simple.tenant.xyz.foo
- broadleaf.tax.provider.simple.foo
If no value can be found, then it moves to the next property. If the applicationId or
tenantId are null, those property resolutions will be skipped.
One thing to be careful of with this approach is that if you are looking for compatible
groups of properties, this can return misconfigurations. Consider, for example, that we have
the following properties:
- broadleaf.tax.provider.simple.application.abc.username=abcUserName
- broadleaf.tax.provider.simple.username=genericUserName
- broadleaf.tax.provider.simple.password=genericPassword
Note that this is misconfigured. If we pass in an applicationId of 'abc', it will try first
to resolve the properties for that applicationId, and then eventually try to resolve the
default property with no applicationId.
So in this example, you will resolve the correct username, but a more generic password
associated with a different username. In other words, property resolution from specific to
general works great for a single property, but you can accidentally mix property values from
different contexts if they are not properly configured or if you simply rely on this approach
to grab multiple, related properties.
To avoid this situation, callers can access the
getApplication()
and
getTenant()
directly to manually resolve properties as
needed.