https://access.redhat.com/security/cve/CVE-2022-34169 is a CVE resolved in OpenJDK via changes like https://github.com/openjdk/jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc. The artifacts produced from the jboss xalan-j fork at https://github.com/jboss/xalan-j/tree/jboss_2_7_1, however, have analogous code to what was fixed in OpenJDK, via the shading of Apache BCEL into the xalan-j jar.

Apache BCEL, which is shaded into upstream Apache Xalan-J applied the equivalent fix:

https://github.com/apache/commons-bcel/commit/f3267cbcc900f80851d561bdd16b239d936947f5

However, JBoss EAP is not impacted by this CVE, since the xalan-j artifact productized by Red Hat does not include the shaded in bcel. Therefore there is not need to incorporate that commons-bcel change into EAP's xalan-j component.

Given that EAP and WildFly have been used for very similar use cases for years now, it seems clear that there's no need to shade in bcel to handle WildFly uses of xalan-j, so I think the fix for this in jboss/xalan-j is to stop doing that. The use case for jboss/xalan-j is to provide a Xalan impl specifically for WildFly's internal needs.