Ability to define order of execution of annotation processors about easy-props HOT 6 CLOSED

@benas thanks for the detailed response. i will try it out by the coming weekend.

from easy-props.

Currently annotation processors are stored in a map and the keyset is used to iterate through them which can lead to different order of execution if a field is marked with multiple annotations.

Are you trying to inject a property from two (or more) different sources on the same field at the same time? Can you give a code example please and explain your expectations? Thank you upfront.

from easy-props.

@Gulats Any update on this?

from easy-props.

@benas yes i am trying to inject a property from more than one source. it is usually a practice to pick up the default parameter from a property but allow the user to override using system/env properties.
here is a simple patch that I created: 6harat@0d1a7aa

which starts honoring the desired annotation order. then the sample code looks like this:

@Getter
@ToString
@Slf4j
public final class Props {

    private static final PropertiesInjector injector = PropertiesInjectorBuilder.aNewPropertiesInjector();
    private static final String PROPERTIES_FILE = "application.properties";
    private static final String PROPERTIES_FILE_DEV = "application-dev.properties";
    private static final String MYX_ENV_KEY = "myx.env";
    private static final String MYX_ENV_VAL_DEV = "dev";

    static {
        if (MYX_ENV_VAL_DEV.equalsIgnoreCase(System.getProperty("myx.env"))) {
            SourceUtil.generateRawStreamUsingSeparator(PROPERTIES_FILE_DEV, null, "=")
                    .forEach(strStream -> {
                        var keyValue = strStream.collect(Collectors.toList());
                        if (System.getProperty(keyValue.get(0)) == null)
                            System.setProperty(keyValue.get(0), keyValue.get(1));
                    });
        }
    }

    @Property(source=PROPERTIES_FILE, key="httpConnectionTimeoutMillis")
    @EnvironmentVariable(value="httpConnectionTimeoutMillis")
    @SystemProperty(value="httpConnectionTimeoutMillis")
    private long httpConnectionTimeoutMillis;

    ...
    
    Props () {
        injector.injectProperties(this);
        System.out.println(String.format("configured props: %s", this));
    }

}

NOTE: the order does not depend on how the user declares it on the field.
e.g. the below order of annotation can be anything:

    @Property(source=PROPERTIES_FILE, key="httpConnectionTimeoutMillis")
    @EnvironmentVariable(value="httpConnectionTimeoutMillis")
    @SystemProperty(value="httpConnectionTimeoutMillis")
    private long httpConnectionTimeoutMillis;

but how we have defined in our contract:

        annotationProcessors.put(Property.class, new PropertyAnnotationProcessor());
        annotationProcessors.put(EnvironmentVariable.class, new EnvironmentVariableAnnotationProcessor());
        annotationProcessors.put(SystemProperty.class, new SystemPropertyAnnotationProcessor());

from easy-props.

ok thanks for the update. However, there are two issues with this approach:

1. The order of property injection is fixed

In your patch, you used a linked hash map which makes the order fixed and pre-defined by the library (Properties file -> Env. variable -> System property). What if I want to inject the value from an environment variable first, and if the key is absent then fallback to the value from a properties file? This is not possible with the suggested approach.

2. Properties will override each other systematically

I tried your patch and noticed that according to the order you defined, the "second" annotation will always override the first one even if the first one is correctly injected:

class Bean {
   @Property(source = "myProperties.properties", key = "bean.name") // Foo
   @SystemProperty(value = "bean.name") // Bar
    private String property;
}

I understand that the order of annotation declaration does not matter and that the order is the one defined in the linked hash map, but in this example, if I have a property bean.name=Foo in myProperties.properties and a system property bean.name=Bar, the bean property will be set to Bar systematically. What I mean is that, If I understand correctly your original request, the goal of adding multiple annotations is to have some kind of fallback mechanism, meaning that if bean.name is not defined in the properties file, only then we should fallback to the system property. But it is not the case here. This is because we don't break out of the loop here once an annotation processor has been applied. So subsequent processors will override the previous ones.

So to sum up, I agree on the idea of composing annotations, but we should find a way to make it possible to:

• Inject a property from a second source only if the first source is not available (missing key, missing file, etc) and not systematically
• Dynamically define the order in which properties should be injected

It is actually possible to do this with the current version using a custom annotation + its processor and leverage existing processors (See example here), but I was thinking about adding an order attribute to all annotations to make it possible to dynamically define the order, something like:

class Bean {
   @Property(source = "myProperties.properties", key = "bean.name", order = 1)
   @SystemProperty(value = "bean.name", order = 2)
   private String property;
}

In this example, I would expect the property to be injected from the properties file first, and if the key bean.name is missing, fallback to the specified system property. The idea is that the order is dynamic, meaning I can also choose to start with the system property first, then fallback to the properties file:

class Bean {
   @SystemProperty(value = "bean.name", order = 1)
   @Property(source = "myProperties.properties", key = "bean.name", order = 2)
    private String property;
}

What do you think? I tried to implement this approach here which is deployed in 3.1.0-SNAPSHOT to see how things work, so I would be grateful if you give it a try and share your feedback. Thank you upfront.

from easy-props.

@Gulats Let's iterate on this. I merged the new order attribute in all annotations to dynamically define the property injection order as described in my previous comment. We can improve things if necessary in the next version.

from easy-props.