Make ConfigWatcher simpler

[pg-yang]

Hi , team
Currently , if we want to add a dynamic config for OAP , we need to create class which extends ConfigChangeWatcher, and add it to ModuleConfig as field , just like:

    @Setter
    @Getter
    private String slowCacheWriteThreshold = "default:20,redis:10";

    @Setter
    @Getter
    private CacheWriteLatencyThresholdsAndWatcher cacheWriteLatencyThresholdsAndWatcher;

And we have to set cacheWriteLatencyThresholdsAndWatcher on module prepare stage , register this watcher through registerConfigChangeWatcher on module start stage .

This is initial idea about simplifying watcher in module config .
Declare interface in library-module, this interface is responsible for transforming property value to an object :

public interface ModuleConfigurationProcessor {
    /**
     * @param propertyValue the value parsed from config property
     * @param targetField   the target of the value would inject
     * @return The final value would be injected to targetField
     */
    Object process(Object propertyValue, Field targetField);
}

ModuleConfigurationProcessor should be defined in ModuleDefine as field , and would be invoked in method ModuleDefine#copyProperties

    private void copyProperties(ModuleConfig dest, Properties src, String moduleName,
                                String providerName) throws IllegalAccessException {
                //....
                Field field = getDeclaredField(destClass, propertyName);
                field.setAccessible(true);
                if (this.moduleConfigurationProcessor != null) {
                    Object propertyValue = this.moduleConfigurationProcessor.process(src.get(propertyName), field);
                    field.set(dest, propertyValue);
                }else{
                    field.set(dest, src.get(propertyName));
                }
              //......
        }
    }

Provide a annotation , such as WatcherBinder in configuration-api module . The annotation could marked on field which type is ConfigChangeWatcher subclass

    @Setter
    @Getter
    @WatcherBinder
    private CacheWriteLatencyThresholdsAndWatcher slowCacheWriteThreshold;

Provide a implementation of ModuleConfigurationProcessor in configuration-api module and set the processor to every
ModuleDefine when config module start ,
In the end , ModuleConfigurationProcessor could transform propertyValue to a Watcher object according annotation WatcherBinder marked on the targetField , also collect these watchers for registering

[wu-sheng]

I can get your idea. Basically, I think it should be good. But there are questions.
Is @WatcherBinder and ModuleConfigurationProcessor duplicated? As this field has to implement one kernel-level interface, which provides the module manager the possibility to initialize this.

[pg-yang]

Yes , @WatcherBinder and ModuleConfigurationProcessor may be duplicated . In fact , we could transform property value according to the type of field .

[pg-yang]

You could have a ConfigValueHolder in library-module, and when initializing field type, if the type instanceofs the ConfigValueHolder interface, you use class#newInstance and call ConfigValueHolder#init to get an instance.

Get an instance of ConfigValueHolder?

as you described ,the field in module config should be defined as

private  SlowDBAccessConfigValueHolder slowDBAccessThreshold;

SlowDBAccessConfigValueHolder should be defined as

class SlowDBAccessConfigValueHolder implementation ConfigValueHolder {
    private SlowDBAccessWatcher watcher= null;
    Object init(String propertyValue, Field targetField){
          // new  an instance of watcher , and hold it 
          this.watcher=new SlowDBAccessWatcher(propertyValue);
          // the targetField is defined as  SlowDBAccessConfigValueHolder  
         // so  the return value should be this (or a new SlowDBAccessConfigValueHolder instance  )
          return this;
    }
 // this method used for getting watcher 
   public SlowDBAccessWatcher getWatcher(){
        return this.watcher;
  }

}

I read this discussion many times and still couldn't understand it .

[wu-sheng]

The above version looks correct already, what else do you not understand?

[pg-yang]

This doesn't seem to reduce the code , instead adding an interface . developers need to implement ConfigValueHolder .

[wu-sheng]

If your point about simpler is to use fewer codes and make the logic hidden by a powerful but explicit framework, then I am afraid that is a principle differential. As I explained, we are not going to do that.
At the beginning of this discussion, I was just feeling, you think two fields are differential, then merge them as one. But it seems I misunderstood your original purpose.

[pg-yang]

Thanks for your time , at least I know the principle