JDK-8031989 : Provide API to get all the JNLP artifacts
  • Type: Enhancement
  • Component: deploy
  • Affected Version: 6-pool,7-pool,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-01-16
  • Updated: 2015-01-22
  • Resolved: 2014-07-11
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 Other
8u40 b01Fixed 9Fixed naFixed
Related Reports
Relates :  
JDK-8031993 - Provide API to check if a given DRS allows or blocks a given application
Relates :  
JDK-8043134 - refactoring existing DRS functionality - splitting RuleId class into smaller classes
Description
This is a request from Java SE Advanced team. We're implementing a tool that will allow Java administrators collect statistics about Java applications (with Java Usage Tracker) and create deployment ruleset based on the collected data.

Java Usage Tracker reports very basic information only. For example, for JNLP applets and Web Start applications it reports JNLP file URL only (sometimes, even this URL is not accessible). However, deployment rules can be created based on other fields, e.g. certificate used to sign jars.

So one of the parts of the tool is for any given URL of a JNLP file get all the artifacts (jars, extensions, etc.) We have basic implementation for this, but it may or may not be exactly the same as what is used by Java Plugin and Web Start. It would be fine if the Deployment team can provide public/internal API for this purpose instead.

There is an alternative approach, though. We can use our own implementation to parse JNLP files. In this case we'll need support from SQE to test if our implementation match the Deployment code, and if it doesn't we'll have to find out if it's a bug in the tool or in JRE.
Comments
8u20 defer request: not a low risk change (~500 lines). DRSTool already uses its own implementation to parse JNLP file and at this point, the API isn't critical for DRSTool in 8u20.
08-07-2014
The current proposal is to serialize/deserialize new AppModel object to plain string and pass the string with UsageTracker data. Review request https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-329
10-06-2014
Dmitry is correct in that the tool needs to be able to get a list of all of the artifacts, JRE version requested and signatures for *both* JNLP and HTML-tag applets. (and JNLP applications too, of course). This could be implemented by parsing the HTML page, having a "dry fire" capability that uses an embedded browser/deploy stack to introspect the requests or perhaps by extending the data that is written into the Usage Tracker to list all of this data. The core use case we're trying to solve is to make is simpler and deterministic when creating rules/rulesets. A workflow that requires developing a DRS file, signing and deploying it, and trying to run each app to see if you correctly identified all of the resources is too cumbersome. Let's identify what we can fix in this process for the 1.0 version, and any gaps will need to be addressed for the next release. Please create P1 enhancement requests for these gaps and target them to 8u40.
27-05-2014
Some thoughts and questions 1) JNLP files As Thomas pointed out, we already have existing classes to parse JNLP files. I'm attaching a simple test that demonstrates how to use this API - LaunchDescFactory.buildDescriptor(���) parses XML file and returns LaunchDesc object that encapsulates information about application descriptor. It's internal API and theoretically it may change in the future. 2) old-style applets and applet with JNLP files I'm not sure that we can expose anything (related to HTML parsing) to reuse in DRSTool as HTML parser is a piece of browser. We have some code that does some HTML parsing in Applet2Viewer but Applet2Viewer is a just tool to run applets outside of browser (this code isn't working for real applets). Is the HTML parsing a part of the request?
21-04-2014
Input is: Web Start apps: JNLP file URL (all but HTTP/GET params) Applets: web page URL (all but HTTP/GET params) + codebase + jnlp_embedded (String) + jnlp_href + code + archive This is the information we get from Java Usage Tracker. Some of the values above can be null, e.g. jnlp_embedded/jnlp_href for legacy/html applets. Output should be: Location (web page URL for applets, JNLP file URL for JNLPs) Codebase Title Vendor Description Main class (code) Security mode (sandbox, all-perms, j2ee-perms) List of jars (URLs) + jar versions List of extensions (URLs) + ext names The next step will be to get the same information about every JNLP extension. The next step will be to get certificate info about every jar. Input will be jar URL + jar versionn, ouput will be a set of certificate chains (e.g. as X509Certificate[]).
14-04-2014
Some initial thoughts: Basically we need something to parse html/jnlp. We have these in LaunchDesc / LaunchDescFactory. And for html, we actually have something in Applet2Viewer and AppletTagParser. We can probably build something out from these existing code to form a new DeployDescriptor that contains all the resources needed by the application/applet. The input is basically a url that points to initial html (applet) or jnlp (application), correct ? Then it should return a new DeployDescriptor object, and you can use the object to get to all the resources needed by the application ? DeployDescriptor parse(URL u) - input URL should be either applet html or webstart jnlp url. I assume you want the API to download the html/jnlps too ? And then we need to define DeployDescriptor class, which should have methods to get all the args needed by the API defined by Andy below ? (docbase, codebase, jnlpUrl, resource[], etc)
11-04-2014
Here is what DRSTool does right now: 1. "VM start" usage tracker records are ignored. 2. Plugin2 records: 2.1 If a record contains "codebase=", use it as the application code base, othewise use applet's web page as the codebase. 2.2 If a record contains "jnlp_embedded=", decode it with Base64.Decoder and parse the JNLP (described below) 2.2.1 If in addition to "jnlp_embedded=" the record also contains "jnlp_href=", use it to extract the JNLP file name 2.3 If a record contains "jnlp_href=", parse the corresponding JNLP file How JNLP files are parsed: 3.1 Input is: codebase (either web page codebase, or applet's codebase) and JNLP location or contents. The location is combined with the codebase to get the final URL of the JNLP file. 3.2 If JNLP file contains "href=" attribute, do JNLP redirection. 3.2.1 If JNLP "codebase=" attribute is empty, use codebase of the JNLP file. 3.3 All the jars and extensions are located relatively to JNLP codebase An example: Web page: http://example.com/applets/index.html Applet: code="Dummy.class" jnlp_href="applet.jnlp" Resulting JNLP file location: http://example.com/applets/applet.jnlp Suppose the jnlp file has the following attributes: <jnlp codebase="blablabla" href="appletjnlp.jnlp"> After redirection we will look for the JNLP file at http://example.com/applets/blablabla/appletjnlp.jnlp 4. Web Start applications 4.1 JUT reports "JavaWS application/applet" records 4.2 These records contain JNLP codebase and original file name. An example: javaws http://example.com/webstart/application.jnlp JUT record: http://example.com/webstart/ -DorigJNLPFileName=http://example.com/webstart/application.jnlp "application.jnlp" will be extracted from the original JNLP file name, appended to the codebase, and the final JNLP file location will be http://example.com/webstart/application.jnlp. Then the same processing as described at step #3 above takes place.
04-03-2014
As I wrote above, the biggest concern is about Java Web Start applications. If user clicks on a .jnlp file in a browser, the file is first downloaded to a temp directory and then launched from there. As a result, JUT reports a valid codebase (if there is no codebase in <jnlp>, it cannot be launched at all), but not the full jnlp file name. -Djnlp.origFilenameArg contains a path to the temp directory, which is useless for us, as DRSTool is launched on a different desktop.
06-02-2014
OK, I should be more specific in this enhancement request. Here is what Java Usage Tracker reports: 1. For applets: web page URL, applet codebase (if provided explicitly), jnlp_embedded/href, code (dummy for JNLP applets). 2. For javaws apps: codebase, original JNLP file name Some of these values are reported literally and doesn't correspond to what is really executed by Java Plugin / Web Start. For example, in the <applet> tag I can specify both code="" and jnlp_href="", and the value of "code" will be ignored, as the class name to run is in jnlp. What information should be provided: 1. URL of the main JNLP file after all the redirects (via href="" in the <jnlp> tag) and codebase resolution. 2. Applet/main class name to execute 3. Application title, vendor, and description 4. Security mode (sandbox, all-permissions) 5. List of main jars (URLs) 6. List/map of JNLP extensions For every JNLP extension we need the same information: URL, class name, title, vendor, description, security, jars, extensions.
06-02-2014
I believe this requirement is bigger than just JNLP. I think what we need is an API that can accept any of the following, and then report back the artifacts we believe the application will require: JNLP file Jar with a signed (embedded) JNLP App descriptor URL of an applet (covers the case where additional JARs are referenced in the applet/object/embed tag, or in the jar manifest)
21-01-2014