JDK-8074402 : Add DRS rules block to Java Usage Tracker records.
  • Type: Enhancement
  • Component: deploy
  • Affected Version: 8u60,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-04
  • Updated: 2017-05-05
  • Resolved: 2015-03-20
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.
JDK 8 JDK 9
8u60Fixed 9 b59Fixed
Related Reports
Relates :  
JDK-8075478 - Update documentation for changes to DRS in 8u60/9
Relates :  
JDK-8046790 - echo elements in ruleset.xml
Description
If the Deployment Rule Set xml file contains any <customer> blocks, they will be ignored by the implementation other than to echo them in an unchecked Trace statement to the console and/or trace file.
This request is also add to the Java Usage Tracker records any <customer> blocks existing within the rule being used.
Comments
after some exchange with DRSTool stakeholders, I will just create a new app_customer=XXX record in the ther JUT record, where XXX is the base 64 encoded customer string for the rule being used. Testing of this is accomplished by using DRS generated from http://oklahoma.us.oracle.com/www/tests/ruleset/ruleset.xml.1.2 and running applications from various locations identified in that ruleset.xml, then noting the output from the trace showing what customer block would be encoded into the JUT record (if JUT was enabled). crucible review (for JDK9): https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-814
06-03-2015
The questions for the DRS Tool team is then: 1.) should we include multiple customer blocks or just the last one ? 2.) do you want the customer block(s) base64 encoded ? (as example below) 3.) if answer to 1.) is yes, do you want as separate records? , such as: > appName: http://java.com/en/download/uninstallapplet.jsp: jnlp_href=../../applet/JavaRemovalTool/launch.jnlp codebase_lookup=false __applet_ssv_version=1.9.0.ea code=com.oracle.javauninstalltool.legacyplugin.LegacyPluginApplet codebase=http://java.com/en/download/ width=571 archive=../../applet/JavaRemovalTool/LegacyPluginApplet.jar id=JUT separate_jvm=true height=400 app_model=eJx9U81uEzEQnjRtk5L+SEUVFQhp ... (900 characters) customer=x9U81uEzEQnjRtk5L+SEUVF{...} customer=njRtk5L+SEUVFQh{...} customer=sad89f76s8d9f7ya8s9{...} or combined into either base64 encoding of compressed form of serialized object as in appModel, or just base64 encoding of the strings themselves. 4.) do you want similar interface for the customer record as we have for the app_model record: (in com.sun.deploy.ref.Helpers) public static String[] restoreCustomersFromString(String JUTCustomerString) throws IOException, ClassNotFoundException { } 5.) finally, would you rather no change to the LUT record, other than adding methods in AppModel to set and fetch the customer records, such that the customer records would be available from the deserialized AppModel Object public static String[] com.sun.deploy.ref.appModel.getCustomerStrings() { }
04-03-2015
Input from Marty and Joe: I met with Joe to get some clarity around his request to pass DRS customer block info to JUT. While I didn���t get any specific use cases in the discussion, Joe did say that he would like to keep this relatively simple: anytime DRS passes information about a rule to the JUT, whether that is an instance of blocking or allowing the rule, it should also pass on any information in a customer block(s) inside that rule. I pointed out that that meant that any customer blocks living outside a rule would not be passed to the JUT. He said he was fine with that as long as that was documented.
04-03-2015