Code Review Request (7161503 subcase) 7142596: RMI JPRT tests are failing

Olivier Lagneau olivier.lagneau at oracle.com
Wed Jul 11 16:16:51 UTC 2012


Darryl Mocek said  on date 7/10/2012 11:17 PM:
> I think pushing what we have now and doing the cleanup after to get 
> the RMI test changes in is the best approach.
I am ok with that approach Darryl.

Olivier.
>
> Darryl
>
> On 07/10/2012 01:52 PM, Stuart Marks wrote:
>> On 7/9/12 11:56 PM, Olivier Lagneau wrote:
>>> Le 10/07/2012 08:49, Olivier Lagneau a écrit :
>>>> Now in the 7161503 SetChilEnv case:
>>>>>
>>>> I think we should just revert to the existing code regarding the
>>>> DebugExecWatcher and related exception cleanup fix.
>>>> We must then accept to keep this exception raised each time 
>>>> runwith() is
>>>> called, since this is the current state of the code.
>>>> We should also then include in bug description a note stating the 
>>>> problem and
>>>> how we can fix it.
>>>> Such a fix would then be part of recent 7168267.
>>
>> Hi Olivier,
>>
>> Thanks for taking time from your vacation to answer this.
>>
>> I'm sure I don't have all the background on this (and I don't really 
>> need to know everything) but from what I recall from talking to 
>> Darryl, 7142596 introduced a test failure that would have to go onto 
>> the problem list; and then 7161503 would fix the failure and then 
>> remove it from the problem list.
>>
>> Instead of fixing these separately we (at least Darryl and I) thought 
>> it would be best to merge them together.
>>
>> Now, I had pointed out some issues with the changes to the 
>> SetChildEnv test. My main concern is that we don't push the changes 
>> as-is and then declare things to be done. If there's further 
>> discussion, design, or cleanup to be done, great, we can push the 
>> current changes and continue working on a followup changeset. If 
>> there's a bugid to track this (probably 7161503) so much the better.
>>
>> If you and Darryl agree to proceed differently, though, I'm fine with 
>> that too.
>>
>> s'marks
>
>




More information about the core-libs-dev mailing list