I'm building a Task Service. Other service can annotate their interface methods with the annotation @Operation. The Task Service will scan for those methods and will offer them to the user for task configuration.
E.g. the Update Service annotates the method
update(String updateFile)with@Operation. The Task Service then can discover and use this method for a scheduled task.
As the method update(String updateFile) needs a path to an update file, the Task Service will require a String input during the task configuration. With reflection, this is easy to determine and to validate.
Now I'm checking if this approach is able to handle a further requirement:
Input values for annotated methods should be pre definable.
Meaning, I somehow need to be able to define e.g. a List of possible input values. ("Update v1",Update v2","Update v3"). I could solve this with an annotation parameter @Operation(inputOptions={"Update v1",Update v2","Update v3"). In static cases this might be an acceptable solution. Update packages although are dynamically available or not. A fix list is not doing it in this case.
Therefor to my idea I would like to have a second thought to:
Sticking to the previous example, the Update Service has another method String[] availableUpdates(), which returns all available update packages. My idea was to give the @Operation another parameter which takes the name of a sibling getter method. @Operation(inputOptionSource="availableUpdates"). With this information, the Task Service could execute the described inputOptionSource method by reflection and retrieve the input options for the actual annotated method.
The full on interface would look like this:
public interface UpdateService{
public String[] availableUpdates();
@Operation(inputOptionSource="availableUpdates")
public void update(String updatefile);
}
Is this a reasonable approach? Or am I tackling this way to complicated? What are the short comings?
Aucun commentaire:
Enregistrer un commentaire