Rick, I fear there are not many options.
ASM is broken in regards to classloading and we had to fix this with overriding a very method.
And this can only be done via reflection if you create a subclass on the fly (using byte code enhancement).
This would be a chicken-egg problem and imo not worth the hassle.
Please note that we do not make things worse: previously there has been a hardcoded dependency to ASM native where we do not know anything about the version, etc. It would be even possible that some projects would not use maven and then you have 2 different ASM libs on the classpath which will get you in deep troubles.
By using our own well known shaded version from our very own xbean project (xbean is an Apache Geronimo sub project), we have at least a guarantee that we do not get into those problems. At the same time we avoid classpath clashes with other ASM versions by strictly using an own shaded package name (org.apache.xbean.asm4).
The dynamic stuff was worth a try, but it turned out that a few bugs in ASM prevent us from doing so.