[JENKINS-60997] Work around BEANUTILS-509

[basil]

Commons BeanUtils apparently has a per thread context classloader (!) data structure that is not thread-safe, which is a correctness issue because the class loader can be shared between multiple threads. Upstream attempts to resolve this issue seem to have stalled over the years.

I audited WrapDynaBean and the only code that seems to read or write to this data structure in practice is org.apache.commons.beanutils.WrapDynaClass#createDynaClass (org.apache.commons.beanutils.WrapDynaClass#clear and org.apache.commons.beanutils.WrapDynaClass#dynaClasses can theoretically read or write to it, but they aren't called anywhere in practice). So serializing access to org.apache.commons.beanutils.WrapDynaClass#createDynaClass should ensure that no two callers interfere with each other.

This PR achieves that objective with a simple private static final (i.e., per-classloader) lock. This does not improve performance, but remember, we are facing a correctness bug, and this does increase correctness. And the performance penalty is negligible—per this page:

In modern JVMs with efficient uncontended synchronization the performance difference is often negligible.

Even with a global lock, I can't imagine enough people rendering Jelly views concurrently for this to be an issue. There would have to be thousands of Jelly views being rendered concurrently, at which point it seems like this global lock would be the least of your worries. Also, the operation under the critical section is just CPU and memory-bound (not I/O), so it should run in a breeze on modern hardware.

This could likely be optimized further, for example by introducing our own ClassValue-based cache of DynaBean instances, but such optimization seems unnecessary in the absence of any evidence that this is a performance bottleneck. Correctness first, then performance. (This PR is about the former.)

Testing done

I tested this by deploying this change to a local controller and running a few Pipeline jobs with no issues.

[jglick]

Loos right. apache/commons-beanutils#95 etc. for comparison. I took the liberty of assigning you to JENKINS-60997 but of course revert if that is a misunderstanding and this (combined with actually bumping the version in Stapler/core of course) is not intended to “resolve” the issue.

[basil]

this […] is not intended to “resolve” the issue

Right, the root cause will be addressed when upstream releases a new version that doesn't attempt to concurrently access a data structure that is not thread safe. This PR "resolves" the symptoms on the Jenkins side by drastically reducing (if not completely eliminating) our exposure to the upstream issue.