On Aug 21, 2013, at 12:46 PM, sebb wrote: > On 21 August 2013 14:48, Christopher Schultz > <ch...@christopherschultz.net> wrote: >> Nick, >> >> On 8/20/13 8:24 PM, Nick Williams wrote: >>> I ran in to a roadblock with this idea. Part of the byte code of a >>> class includes the fully-qualified class name. If I create a class, >>> say UnweavedClass, and replace its byte code in my fake transformer >>> with that of another class, the FQCN changes. This results in a >>> NoClassDefFoundError because the class loader is looking for >>> UnweavenClass in be in the byte code when really some other class >>> is. >>> >>> My backup idea is slightly less clean but, IMO, still more clean than >>> adding ASM as a test-time dependency and trying to figure all of that >>> out. I locally compiled fake "weaved" versions of the UnweavedClass >>> (with the modified behavior) and then translated each version into a >>> Java byte array definition. (These are extremely simple on-line, >>> one-method classes, so the byte arrays are relatively short.) I then >>> simply embedded the byte array definitions as static final byte[] >>> fields the test class and replaced the byte code in my fake >>> transformer with those embedded fields' content. I've tested this and >>> it works great. >> >> Any reason not to simply compile some .java source into a .class file >> and read it from the disk instead of shoving it into a byte array? >> There's nothing stopping you from doing an offline-compile of a .java >> file into a .class file and committing both to svn. You don't have to >> compile the .java source as part of the test -- just load it off disk as >> part of the test. >> >> This will allow easier inspection of the .class file, and not be such a >> pain in the neck to change the bytecode if necessary. > > Is there any mileage in using the features of JSR199?
That would require a bit more code than the current solution Mark and I agreed on. The approach I took was the simplest approach possible, IMO. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
