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?

> -chris
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to