JDK-5066440 : Overwrite trace property doesn't seem to work well in 1.5.b56
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2,6
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-06-22
  • Updated: 2005-11-30
  • Resolved: 2004-09-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_09Fixed 6 mustangFixed
Description
http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/tracing_logging.html 

According to the end part of the above  page,
when we specify the property 
  javaplugin.outputfiles.overwrite=false 
we can get the trace file and log file as the following name.

.plugin<username><date hash code>.trace and .plugin<username><date hash code>.log 

In other words, we hope the trace and log information for each session
respectively.
However, even when we set javaplugin.outputfiles.overwrite=false ,
We still get the
    .plugin<version>.trace and .plugin<version>.log 
under the F:\Documents and Settings\<user>\Application Data\Sun\Java\Deployment\log

REPRODUCE :
    1) Open the java control panel in [start]-[control panel]
    2) click the tab [java] and open the setting runtime.
    3) Specify the properties as follows.
        -Djavaplugin.trace=true -Djavaplugin.trace.option=basic|net|security|
ext|liveconnect -Djavaplugin.logging=true -Djavaplugin.outputfiles.overwrite=false

    4) Look at the F:\Documents and Settings\<user>\Application Data\Sun\Java\Deployment\log
       The trace file and log file name is
         .plugin<version>.trace and .plugin<version>.log 

EXPECT : 
   We can getthe trace and log files in 
    .plugin<username><date hash code>.trace and .plugin<username><date hash code>.log 
   as the web page expains.

ACTUAL : 
    plugin<version>.trace and plugin<version>.log 

CONFIGURATION:
   OS : WIndowsXP(SP2, Japanese)
  JRE : 1.5.0-beta3-b56
  Browser : IE 6.0 (SP1)

========================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang FIXED IN: mustang INTEGRATED IN: mustang
08-09-2004

EVALUATION I tried described feature with JRE 1.4.2 and was not able to get it working, so this is not a regression. Wording "doesn't seem to work well" is not exact, since if you try to turn tracing/logging properties "ON" through vm args, it does not work at all. On the positive side, users can turn tracing/logging through "Advanced" tab in Control Panel for jre 1.5.0. This is not a show stopper. Lowering the priority and committing to next release. I think we should update documentation and remove the last paragraph completely from the developers' guide. ###@###.### 2004-06-23 I investigated this bug further. There are two issues here: 1. The fix for the problem is in UserProfile.java at line 63. This line should be if (overWrite.equals(Boolean.FALSE)) i.e. should use equals to compare Boolean objects, not == This is where we arrive at the second issue. 2. If above fix applied, this feature will start working (according to the file history this feature never worked, since above error was there from day one), and default behavior for the trace file name would be to always generate new name. Currently, we overwrite plugin<version>.trace file. New behavior is due to the fact that if property has not been specified, "false" would be returned from doPrivileged(Action). In our case, if -Djavaplugin.outputfiles.overwrite option is not specified, doPrivileged(Action) will return "false", which is the default value to turn this feature "ON". We should probably change this property name to reflect the actual meaning with "true" being default value to turn the feature "ON". Since we have not heard any complaints about this feature not working, I suspect that it has not been used much, so changing property name would not have too much impact. ###@###.### 2004-06-30 It was decided at the engineering meeting to fix the incorrect behavior without introducing a new option name (for now). ###@###.### 2004-08-09
30-06-2004