Class DiscriminatedProperties<P>

  • Type Parameters:
    P -
    Direct Known Subclasses:
    SimpleTaxProperties, TaxDelegateProperties

    public abstract class DiscriminatedProperties<P>
    extends Object
    Mechanism to allow us to specify tax properties defined for different tenants and/or applications. This is useful when different tenants or applications use different tax providers, or where they have different credentials or company identifiers with those tax providers.
    Author:
    Kelly Tisdell (ktisdell)
    • Constructor Detail

      • DiscriminatedProperties

        public DiscriminatedProperties()
    • Method Detail

      • getField

        protected <T> T getField​(String fieldName,
                                 @Nullable
                                 String applicationId,
                                 @Nullable
                                 String tenantId)
        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:
        1. broadleaf.tax.provider.simple.application.abc.foo
        2. broadleaf.tax.provider.simple.tenant.xyz.foo
        3. 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:
        1. broadleaf.tax.provider.simple.application.abc.username=abcUserName
        2. broadleaf.tax.provider.simple.username=genericUserName
        3. 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.
        Type Parameters:
        T -
        Parameters:
        fieldName -
        applicationId -
        tenantId -
        Returns:
      • getField

        protected <T> T getField​(String fieldName,
                                 @Nullable
                                 com.broadleafcommerce.data.tracking.core.context.ContextInfo contextInfo)
      • getApplication

        public Map<String,​P> getApplication()
      • setApplication

        public void setApplication​(Map<String,​P> application)
      • setTenant

        public void setTenant​(Map<String,​P> tenant)