Lloyd Chambers wrote:
> Ken,
>
> I could handle the glassfish side of things, so long as I know what to
> change. Do we still have the ugly scenario of many places defining
> their own version?
>
> If it's one place in pom.xml, then it's easy.
I think the only place is gmbal.version in the top-level pom.xml. Easy
enough to change,
but are the QLs sufficient testing for this integration? There are a
couple of other changes here as well,
because b011 never got integrated into GFv3 (b010 is the current
version). This will also fix the swapped type
and description problem.
I just pushed gmbal version 3.0.0-b012 to maven (the files take about 30
minutes to get there).
If everyone agrees that running the QL tests is sufficient to integrate
gmbal, go ahead and integrate the fix.
That's the best possible solution to our "known failure" discussion.
(I have written a new unit test for the failure, and all of my unit
tests pass. I have NOT run the QL tests with
the new gmbal at this point).
Thanks,
Ken.
>
> Lloyd
>
> On Sep 4, 2009, at 2:25 PM, Ken Cavanaugh wrote:
>
>> 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.
>> Actually the problem is in Gmbal. The ORB defines CompositeData with
>> a field of type byte[] which must be converted to Byte[] in order to
>> work with JMX. Since the Gmbal currently in GFv3 doesn't do that, we
>> see a problem.
>>
>> I have the fix ready to go, we just need to integrate a new gmbal.
>> Jennifer Chou has been doing the gmbal integrations, but I think
>> she's on vacation this week, so hopefully
>> we can get this done early next week. I could integrate Gmbal myself
>> and run the QL tests, but I don't know
>> what other tests Jennifer might be running for integrating a new Gmbal.
>>
>> I agree with Lloyd, turning off a test is a bad idea. I'd rather be
>> annoyed with a known failure than forgot to
>> turn a disabled test back on after the fix is available.
>>
>> Ken.
>>>
>>> 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.
>>>
>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>