Verify that Module Descriptor changes are backwards compatible
- Viktor Gema
Spike Overview
JIRA ID: EUREKA-52 Verify that Module Descriptor changes are backward compatible
Objective: The application descriptor is not valid for the OKAPI platform after introducing the new property 'user'.
Problem Statement
The changes required for the EUREKA platform need to be put in the application descriptor. However, the new property does not exist in the OKAPI platform and throws an error during the parsing of the descriptor. We need to define a solution to resolve this issue.
Research Questions
Does the module descriptor with the new 'user' property not corrupt the OKAPI platform?"
Deliverables
Option 1 Update JSON mapping for ModuleDescriptor object
The approach requires updating the OKAPI code to properly handle a new property in the module descriptor. If the property is specified, the code should simply ignore it as there is no need to take any action
Implementation
The implementation will require adding the JsonIgnoreProperties annotation, which allows parsing the updated descriptor without errors.
@JsonInclude(Include.NON_NULL)
@JsonIgnoreProperties
public class ModuleDescriptor implements Comparable<ModuleDescriptor> {
private ModuleId id;
private String name;
Pros
Cons
It can be extended with additional properties, which can make the module descriptor file unreadable and the data within it unclear
Option 2 Add new property into ModuleDescriptor called “extensions”:
The approach will introduce a new property (chapter) that can be of any type of object, serving different purposes depending on the requirements. In our case, we will introduce users for the EUREKA platform, potentially using it to define the payload version for Kafka messages.
Implementation
The implementation will require introducing the new property with any type of object.
public class ModuleDescriptor implements Comparable<ModuleDescriptor> {
private ModuleId id;
private String name;
private String[] tags;
private InterfaceDescriptor[] requires;
private InterfaceDescriptor[] provides;
private InterfaceDescriptor[] optional;
private RoutingEntry[] filters;
private Permission[] permissionSets;
private EnvEntry[] env;
private AnyDescriptor metadata;
private AnyDescriptor extensions;
private UiModuleDescriptor uiDescriptor;
Option 3 Use existing property “metadata“
Currently, OKAPI has a property for the module called 'metadata,' which can contain objects of any type
Implementation
We can embed the EUREKA object for system users into an existing property and parse it, while OKAPI will ignore it at the same time.
"metadata": {
"user": {
"type": "module",
"permissions": [
"inventory-storage.inventory-view.instances.collection.get",
"inventory-storage.identifier-types.collection.get",
"inventory-storage.alternative-title-types.collection.get",
"inventory-storage.call-number-types.collection.get",
"users.collection.get",
"user-tenants.collection.get"
]
}
},Pros
There is no need to modify the OKAPI code.
Cons
Risks & Assumptions
Choosing Option 1 or Option 2 will require updating the OKAPI platform otherwise module descriptors file will be incorrect.
Conclusion
I recommend choosing Option 2 because it will introduce a new common capability for adding extensions to the module descriptor. This can be used for various purposes and will provide us with the flexibility to integrate new functionality into the OKAPI or EUREKA platform.
Spike Status: Complited