tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Need guidance for writing unit tests for 55317
Date Wed, 21 Aug 2013 19:21:28 GMT
Sebb,

On 8/21/13 1:46 PM, sebb wrote:
> On 21 August 2013 14:48, Christopher Schultz
> <chris@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.

-chris


Mime
View raw message