On 21 August 2013 20:21, Christopher Schultz <ch...@christopherschultz.net> wrote: > Sebb, > > On 8/21/13 1: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? > > Is that widely-deployed? I don't believe its a part of, for instance, > Java 7 SE.
I understood it to be part of Java 6 [1], but perhaps I misunderstood. Alternatively, since Tomcat uses ECJ, it could perhaps use that to compile. The Commons JCI component has an Eclipse compiler; however there is an issue with it at present [2] [1] https://blogs.oracle.com/jjg/entry/jsr_199_meets_jsr_203 [2] https://issues.apache.org/jira/browse/JCI-59 > -chris > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
