RFR 8028141 intermittent test failure of LocalManagementTest
chris.hegarty at oracle.com
Tue Nov 19 04:01:39 PST 2013
Thanks for the reply. I agree completely with your explanation.
I understand there are multiple efforts running to address this issue,
so I'll leave it to yourselves to work out the details, but as far as a
point fix, yours is good.
On 11/19/2013 01:09 AM, roger riggs wrote:
> Hi Chris,
> Here's an example from a failing test run:
> Note that test.classes does not include the @library path lib/testlibrary.
> So if lib/testlibrary is supposed to be available to the spawned process
> then using test.class.path is needed.
> Including @build will compile the library classes into /lib/testlibrary
> but that's not enough.
> It happens that if the classes are not already compiled in
> lib/testlibrary (and there is no @build)
> then the files will be compiled on demand by javac into the test.classes
> And in that case they are 'accidentally' available to the spawned
> process but by using @library
> that does not seem to be the intention.
> The test fails if the lib/testlibrary classes have been compiled by a
> previous test.
> Yes, there are other tests using jdk.testlibrary that do not have the
> there maybe some tests that fail to pass the full test.class.path.
> I'll recheck , but that's out of scope for the particular issue.
> Thanks, Roger
> On 11/18/2013 5:25 PM, Chris Hegarty wrote:
>>> On 18 Nov 2013, at 21:59, roger riggs <roger.riggs at oracle.com> wrote:
>>> Please review this fix to improve the reliability of the
>>> jmxRemote/LocalManagementTest and CustomLauncherTest. The solution
>>> may apply to other tests that fail with ClassNotFound.
>>> The tests did not include the jdk.testlibrary in the classpath when
>>> it spawns a new process. The failure mode is dependent on the order
>>> that tests had been run.
>>> Also note that if a test depends on classes in the jdk.testlibrary it
>>> should include @build <classname> to ensure they are built in the
>>> @library directory
>> I've come across some of these before. The changes to the tags make
>> About the change to the property, test.class.path, I thought
>> test.classes was right. Is this different from what other tests are
>>> Thanks, Roger
More information about the serviceability-dev