| Task |
Pri |
For TP2 |
For Beta |
For Post-beta |
|
Engg |
Help to QE |
Doc |
Total |
Notes |
| Scripting (RC-1) |
P2 |
|
X |
|
|
0.5 |
0.5 |
~0 |
1 |
Scripting support is already in GF as a technology preview. JavaFX Script is emphasizing compiling scripts to Java classes, in which case users will be able to build app clients as they always have and specify the main class that results from the JavaFX Script compilation as the main class for the app client. |
| ACC as HK2 module (RC-2) |
P2 |
X |
|
|
|
3 |
0 |
0 |
3 |
Some uncertainty on which dependencies will be satisfied by JARs (e.g., the ORB) and which by modules |
| Embeddable ACC (RC-4) |
P3 |
|
X |
|
|
1 |
0 |
0.5 |
1.5 |
Would include retrofit of Java Web Start support to use embedded ACC |
| Add host and port as cmd line args (RC-3) |
P3 |
|
|
X |
|
0.5 |
0 |
0.5 |
1 |
|
| Traditional cmd line processing (RC-5) |
|
|
|
|
|
|
|
|
0 |
Early investigations to use Java agent technology to trigger the ACC revealed problems with that approach. Need to nail down if there are other refinements to the appclient command that this requirement now implies. |
| Custom JNLP (RC-6, RC-7, RC-8) |
P2 |
|
X |
|
|
2 |
0.5 |
0.5 |
3 |
I had prototyped some of this feature long ago so a possible implementation of the XML merging logic exists. RC-7 (shortcut creation for Java Web Start-launched app clients) and RC-8 (splash screen) will both be met by this broader task. |
| Splash screen via appclient command (RC-8) |
P2 |
|
X |
|
|
0.5 |
0 |
0.5 |
1 |
Must be addressed separately from the Java Web Start splash screen solution |
| JWS use individual JARs, not the generated app client JAR (RC-2) |
P2 |
|
X |
|
|
1 |
0 |
0 |
1 |
Allows JWS launches to avoid expanding the generated AC JAR into a temp directory so the contained JARs can be added to the class path. Instead, the JNLP would refer directly to the contained JARs on the server. Should yield significantly faster start-up of JWS launches and improved caching by JWS. |
| Create JWS "bootstrap" client JAR as part of deployment (RC-2) |
P2 |
|
X |
|
|
1 |
0 |
0 |
1 |
Bootstrap JAR is the small but main JAR for the client for JWS launches. Includes Class-Path & indexing for optimized downloads. |
| Use JWS security |
|
|
X |
|
|
1 |
0 |
0.5 |
1.5 |
V2 JWS ACC dynamically modifies security policy to grant permissions to GF JARs. Reduced footprint should reduce the number of GF JARs needed. Remaining ones should be signed so the JWS security mechanism can work. Insulates against further evolution of JWS security implementation. |
| Investigate using only the JWS class loader |
|
|
X |
|
|
1 |
0 |
0 |
1 |
V2 JWS ACC prepares EJBClassLoader and bypasses the JWS class loader, requiring cumbersome probes to locate the GF JARs downloaded by JWS that then need to be added to the EJBClassLoader's path. Better: rely on JWS mechanisms and only the JWS class loader to insulate from JWS evolution. (JWS ACC already must prepare differently if JWS is from Java 5 or 6.) Questions: persistence requires the CL to be instrumentable; even if JWS CL is instrumentable, will need to test this thoroughly. |
| ACC changes due to app versioning |
|
|
|
|
|
|
|
|
0 |
Need to investigate |
| Simplify scripts (RC-5) |
P3 |
|
X |
|
|
1 |
0 |
0.5 |
1.5 |
V2 appclient scripts contain significant logic that should migrate to Java, to simplify the scripts themselves and to further unify the JWS and non-JWS launch code path. |
| App Client module type archive handler, sniffer, deployer |
|
X |
|
|
|
2 |
0 |
0 |
2 |
Part of modularization of GF and archive types |
| New default login callback handler |
|
|
|
X |
|
0.5 |
0 |
0 |
0.5 |
Largely done. Users have complained about the V2 default callback handler. I already have a nearly-completed and much more complete version (handles the full set of callbacks in the spec in contrast to the one in V2). |
| Naming ? |
|
|
|
|
|
|
|
|
0 |
Early progress on V3 ACC may require my work on naming, perhaps on both the client and server side. TBD |
| |
|
|
|
|
|
|
|
|
|
|
| Total |
|
5 |
12.5 |
1.5 |
|
15 |
1 |
3 |
19 |
|
