#311: dependency updates (spring-boot 2.4.0, spring-cloud to 2020.0.0, cxf to 3.4.1, etc.)

[hohwille]

This PR implements issue #311 and includes several dependency updates to solve CVEs and be up-to-date:

• update spring-boot to 2.4.0 (from 2.3.3.RELEASE)
• update spring-cloud to 2020.0.0 (from Greenwich.SR6)
• update CXF to 3.4.1
• update guava to 30.0-jre (from 28.0-jre)
• update junit to 5.7.0 (from 5.6.1)
• update slf4j to 1.7.30 (from 1.7.28)

Besides I included:

• resolved Eclipse warnings for 2 classes in archetype (unused import/generic typing)
• improved CXF error handling (including workaround for bug https://issues.apache.org/jira/browse/CXF-8408).

Obsolete (all resolved with spring-cloud 2020.0.0): With spring-cloud Hoxton.SR9, the kafka stuff breaks into pieces:

• for unclear reasons we used brave.internal.HexCodec.toLowerHex to convert a number to its hex value. Why do we need an external lib for this (instead of using java.lang.Integer) and especially from an internal package. However, just the package changed so I could fix this one easily.
• org.apache.kafka.clients.producer.ProducerRecord has changed its API in an incompatible way. I have fixed this and hope I did well.

The major remaining problem is that spring-cloud is based on a long deprecated class ConfigurationBeanFactoryMetadata from spring boot that has been removed in 2.4.0. However this is still included in the latest spring-cloud release.
JUnit test therefore fails with:

Caused by: java.lang.ClassNotFoundException: org.springframework.boot.context.properties.ConfigurationBeanFactoryMetadata
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 110 common frames omitted

Real cause is hard to trace but I found it here:
spring-cloud/spring-cloud-config#1543

[hohwille]

So I currently see the following options:

• wait for an update of spring-cloud that is compatible with the spring-boot 2.4.0
• remove spring-cloud from our kafka module. It seems to be mainly used for open-tracing. As we have planned open-tracing support in general (not only for kafka) with issue Support for opentelemetry #260, it makes sense to consider in general what libs to use accross all technologies (rest, kafka, soap, etc.).

As a result I think we can not update to spring-boot 2.4.0 for release 2020.12.001.

[hohwille]

New version of spring-cloud available: https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-dependencies/2020.0.0/

[hohwille]

Latest error is now CxfRestClientTest failing with NPE at:

devon4j/modules/cxf-client-rest/src/main/java/com/devonfw/module/cxf/common/impl/client/rest/RestServiceExceptionMapper.java

Line 50 in 466368d

String serviceDetails = this.context.getServiceDescription(operation, url.toString());

because url is null.
Looks like a regression bug in CXF due to upgrade.

[hohwille]

maybe we should return null instead?

[hohwille]

hopefully we should never get here either...

[maihacke]

maybe return "" is even safer to avoid NPE.

[hohwille]

Its a private method that is only used in a single place to pass it to getServiceDescription here:

devon4j/modules/cxf-client-rest/src/main/java/com/devonfw/module/cxf/common/impl/client/rest/RestServiceExceptionMapper.java

Line 58 in 0ac5c96

String serviceDetails = this.context.getServiceDescription(operation, url);

That method honors null but not the empty String as the idea was that null means not available:

devon4j/modules/service/src/main/java/com/devonfw/module/service/common/api/client/context/ServiceContext.java

Line 63 in 0ac5c96

default String getServiceDescription(String operation, String url) {

However, we could also return "" and also change getServiceDescription to treat "" just like null.

[maybeec]

Do we need any upgrade script as well for the devonfw ide? Do we already have a ticket and identified the issues to be migrated next to the version numbers?

[hohwille]

@maybeec thanks for your review and approval.
Thanks for asking about migration:
We always follow provide a release of devonfw-ide after a new release of devon4j including the migration logic.
To ensure QA, I already added a test-case in devonfw-ide long time ago that retrieves the latest devon4j version from maven central and checks that devonfw-ide is updated to that version. In devonfw-ide there is a test creating an old OASP4j 2.6.0 app and step by step migrating to the latest version of devon4j. Then it also builds that project to see that the resulting build and tests are working.
The a little bit annoying effect is that CI of devonfw-ide breaks whenever we do a devon4j release what sometimes can confuse contributors when their PRs get red in travis but in the end it is the best way to ensure quality and that we do not forget to add the migration.

[hohwille]

I will merge this tomorrow but I guess all is fine now.