Code Review Request (7161503 subcase) 7142596: RMI JPRT tests are failing
olivier.lagneau at oracle.com
Wed Jul 11 15:16:36 UTC 2012
Stuart Marks said on date 7/10/2012 10:52 PM:
> 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.
Yes that's it.
> Instead of fixing these separately we (at least Darryl and I) thought
> it would be best to merge them together.
Sure I completely agree with this since 7161503 is a subpart of 7142596
> 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.
I am ok with this too.
> 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.
I will prepare quickly a patch fixing and suppressing DebugExecWatcher
class (the fix I exposed previously).
We should discuss tomorrow by phone with Darryl on amother subject, we
will add that to the agenda and sync together on the way to proceed
(wether or not we use the same bug id )
> If you and Darryl agree to proceed differently, though, I'm fine with
> that too.
More information about the core-libs-dev