On 9/4/09 17:16, Lloyd Chambers wrote:
> Abhijit is trending strongly towards disabling the test for this
> reason (confusion).
>
> They indicate real problem with the ORB MBeans, but not problems that
> affect the overall server operation.
>
> So what it comes down to is what our policy in removing tests that
> detect real problems? I think it's kinda lame to have tests, then
> turn them off when real problems crop up.
>
> My other suggestion was to have the test itself emit a message
> indicating that it is a known issue.
>
> I have NOT seen amxtest.AMXCoreTests.iterateAllSanityCheck() fail, so
> that one needs looking into.
Ok, so the other one is known, but this one is not. Hmm. I guess I will
look into it. :-(
Here is the stack trace:
java.lang.NullPointerException
at amxtest.AMXCoreTests.iterateAllSanityCheck(AMXCoreTests.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:470)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:678)
at org.testng.TestRunner.privateRun(TestRunner.java:624)
at org.testng.TestRunner.run(TestRunner.java:495)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:300)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275)
at org.testng.SuiteRunner.run(SuiteRunner.java:190)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792)
at org.testng.TestNG.runSuitesLocally(TestNG.java:765)
at org.testng.TestNG.run(TestNG.java:699)
at org.testng.TestNG.privateMain(TestNG.java:824)
at org.testng.TestNG.main(TestNG.java:802)
-> richard
>
> Lloyd
>
> On Sep 4, 2009, at 1:54 PM, Kedar Mhaswade wrote:
>
>> I get the failure with:
>> amxtest.AMXCoreTests:testAMXComplianceMonitorFailureCount
>>
>> It's not clear if that's the same as the one reported in 9355.
>>
>> BTW, can we temporarily disable the test so that we get a clean
>> run every time? When the bug is fixed, we can re-enable it.
>>
>> Thanks.
>>
>> Jane Young wrote:
>>> I know #2 is a known issue. See IT 9355
>>> and
>>> http://gf-hudson.sfbay.sun.com/hudson/job/gf-trunk-build-continuous/2205/artifact/bundles/QL-GP-report.html
>>>
>>> I'm not sure about #1. Are you getting total of 2 failures or 1?
>>
>>> Richard S. Hall wrote:
>>>> Hello,
>>>>
>>>> I am trying to make sure that Felix 2.0 is ready for release. My
>>>> latest run comes up with the following QL failures:
>>>>
>>>> 1. iterateAllSanityCheck
>>>> java.lang.NullPointerException
>>>> at
>>>> amxtest.AMXCoreTests.iterateAllSanityCheck(AMXCoreTests.java:94)
>>>> 2. testAMXComplianceMonitorFailureCount
>>>> java.lang.AssertionError: Server indicates that there are
>>>> non-compliant AMX MBean validator failures, failure count = 20,
>>>> examine the server log for failures
>>>> at
>>>> amxtest.AMXCoreTests.testAMXComplianceMonitorFailureCount(AMXCoreTests.java:112)
>>>>
>>>>
>>>> Are these normal failures in GF trunk?
>>>>
>>>> -> richard
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish Team
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>