RFR 9: 8034903: Add Logging of Process.start arguments and resulting pid

roger riggs roger.riggs at oracle.com
Fri Feb 14 16:21:04 UTC 2014


Thanks Paul, Daniel,

Thanks for the suggestions,  I updated the webrev.

/othervm does seem to be needed to prevent this test from interfering or
being interfered wit.

Roger


On 2/14/2014 6:06 AM, Daniel Fuchs wrote:
> Hi Roger,
>
> I agree with Paul that using Objects.toString(environment) would be
> cleaner.
>
> Concerning the test, you may want to modify CheckHandler.publish to
> filter out any log record that doesn't come from your ProcessImpl
> classes. Something like:
>
>  175         @Override
>  176         public void publish(LogRecord lr) {
>                  // Only look at the records emitted by the
>                  // "java.lang.Process" logger
>                  if ("java.lang.Process".equals(lr.getLoggerName()) {
>  177                logRec = lr;
>                  }
>  178         }
>
> Also, since you're changing the Level of the root logger, you may
> want to either run your test in /othervm mode, or make sure that it
> puts back the root logger level to its original value and also
> removes the CheckHandler() instance from the root handlers with a try {
> } finally { } to avoid polluting the other tests that will follow.
>
> best regards,
>
> -- daniel
>
> On 2/13/14 10:26 PM, roger riggs wrote:
>> Hi,
>>
>> Having folks stumbling over process creation and problems of quoting,
>> especially on windows, it seems useful to log the native commands and
>> arguments.
>> They are proposed to be logged using the PlatformLogger at Level.FINE
>> which will not be logged by default. The environment is useful in some
>> cases,
>> but verbose, that it should be Logged at FINER.  The pid of the spawned
>> process
>> logged as well for traceability.
>>
>> Please take a look at this first draft and comment on whether it is 
>> useful,
>> a good idea and any improvements needed.
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-log-processcreate/
>>
>> Thanks, Roger
>>
>




More information about the core-libs-dev mailing list