Alfresco 6.2.1 support

[kerkhofsd]

Alfred Telemetry currently doesn't work Alfresco EE 6.2.1.

Root cause:
Alfresco has upgraded the versions of the Micrometer libraries. This version (1.3.5) has incompatible API changes in comparison with the version used in Alfred Telemetry (1.0.6).

root@7f786aefcb61:/usr/local/tomcat/webapps/alfresco/WEB-INF/lib# ll | grep micro  
-rw-r--r-- 1 root root   353551 Apr 21 17:46 micrometer-core-1.0.6.jar
-rw-r--r-- 1 root root   473522 May 12 11:39 micrometer-core-1.3.5.jar
-rw-r--r-- 1 root root    16832 May 25 15:16 micrometer-jvm-extras-0.1.2.jar
-rw-r--r-- 1 root root     9561 May 25 15:16 micrometer-registry-graphite-1.0.6.jar
-rw-r--r-- 1 root root     3685 May 25 15:16 micrometer-registry-jmx-1.0.6.jar
-rw-r--r-- 1 root root    24735 May 25 15:16 micrometer-registry-prometheus-1.0.6.jar
-rw-r--r-- 1 root root    25865 May 12 11:39 micrometer-registry-prometheus-1.3.5.jar

Stacktrace (one of the many):

[ALFRESCO] 2020-05-27 06:43:50,612  ERROR [web.context.ContextLoader] [localhost-startStop-1] Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'alfred-telemetry.Care4AlfMeterBinderRegistrar' defined in class path resource [alfresco/module/alfred-telemetry-platform/context/binder-context.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: 'void io.micrometer.core.instrument.Meter$Id.<init>(java.lang.String, java.lang.Iterable, java.lang.String, java.lang.String, io.micrometer.core.instrument.Meter$Type)'

[kerkhofsd]

The specific problem, causing the mentioned stacktrace is caused by a signature change of the Meter.Id ctor:

public Id(String name, Iterable<Tag> tags, @Nullable String baseUnit, @Nullable String description, Type type) {
// changed to:
public Id(String name, Tags tags, @Nullable String baseUnit, @Nullable String description, Type type) {

On first sight, it is possible to make Alfred Telemetry work in Alfresco 6.2.1 by doing the following:

• compile against and ship with micrometer 1.3.5 (= the version that is used in Alfresco 6.2.1)
• replace Iterable<Tag> with Tags where used in the Meter.Id(...) ctor

Implications on other Alfresco versions:

• for Alfresco < 6.1, micrometer is not included and therefore an upgrade in our AMP shouldn't be a problem.
• for Alfresco = 6.1, micrometer 1.0.6 is included OOTB. Therefore this will only work if there are no incompatible changes between the Alfresco & Alfred Telemetry version (1.3.5). By replacing Iterable<Tag> with Tags, we fixed an incompatible issue we immediately noticed. Are there others?

My main concern remains: although it seems we can now work around an incompatible change, how will we handle synergie with the versions of Micrometer shipped by Alfresco in the future?

[kerkhofsd]

Correction: replacing Iterable<Tag> with Tags where used in Meter.Id(...) does not work on Alfresco 6.1:

Caused by: java.lang.NoSuchMethodError: 'void io.micrometer.core.instrument.Meter$Id.<init>(java.lang.String, io.micrometer.core.instrument.Tags, java.lang.String, java.lang.String, io.micrometer.core.instrument.Meter$Type)'

(Even though Tags implements Iterable<Tag>)

[kerkhofsd]

Summary of discussion with @tgeens :

• it looks like the signature of the Meter.Id(...) constructor invoked is hared-wired at compile time.
• possible fix: invoke ctor via a meter-factory that uses reflection to instantiate the Meter.Id
• possible fix: ship 2 different class files for the impacted MeterFilters and decide at runtime which one to invoke.

I had another look in the usages of the Meter.Id(...) ctor and I think this can be replaced by compositing some out of the box MeterFilter implementations. Removing the Meter.Id(...) invocation from our code could be a workaround for now.