library surface reduction

[DaanHoogland]

library interface surfaces should be reduced to improve portability and upgradability. examples of lockins that cloudstack suffers from are gson, stringutils and even the completely Apache internal log4j1.2 to log4j2 upgrade is a problem because of this.
jira issue CLOUDSTACK-10089 asks for a log4j update.
other issues have been encountered in teh past (will add references if i encounter them)

ISSUE TYPE

• Improvement Request

COMPONENT NAME

cross cutting concern

CLOUDSTACK VERSION

all

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

I think a number of PR need to be created for the mentioned utilities and maybe others to smoothly get to a maintainable situation.
Each of them must have all functionality used in CloudStack proxied in them.

STEPS TO REPRODUCE

when upgrading or migrating from a library to a library of similar funvctionality, changes should only have to be made in one area of the cloudstack code base. This is the ideal situation and may never be true for 3rd party plugins for instance. Big improvements can be made however on the mentioned libraries
* StringUtils
* Gson (json utilities)
* logging

EXPECTED RESULTS

one class or package at most has to be changed when upgrading or migrating

ACTUAL RESULTS

a plethora of hundreds of files need to be changed for each upgrade, risking numerous regressions due to oversights or misinterpretations of coding styles.

PR list (will be trying to include dependencies in a tree like structure, here)

[ ] #2992

[DaanHoogland]

several related PRs are merged but real broad support for this is not found. Not losing hope yet.

A recent PR does something like it for StringUtils, at least standardising it.

[yadvr]

@DaanHoogland can we close this if we move to log4j 2.x in near future or is this still applicable?

[DaanHoogland]

I will have to find new ways to get the idea into the heads of the community. This remains an issue we'll keep facing.