EVALUATION
Problem:
Shortcut stops working if jnlp file changed on server while running single instance application
two issues shown by the customer's application:
1. if another instance of a single instance application is started and we need to go to the java code, we should not update the cached jnlp. instead, as soon as we got a LaunchDesc, we should check if another instance of the application is running, and signal and exit if necessary.
2. launching of the second instance via jnlp file directly should not launch java at all. the native code should be able to signal the current running instance already. problem here is the customer's jnlp file uses multiple resources element, and main=true is not specified. our native code fail to read the correct resources element to find out the first jar as main jar.
Fix:
1. check for single instance as soon as we have a LaunchDesc
2. native code should process the valid resources element to find out the main jar
testcase: http://web-east.east.sun.com/deployment/www/tests/1.6.0_10/6549428/
|
EVALUATION
i can reproduce the problem with customer's test case.
customer's jnlp application is using single instance service, and registered as a single instance application.
if you just close the application window, the instance won't go away, and now if you click on a different jnlp file, the single instance code will bring up the application using the running jvm again, but also it will update the cached jnlp, but not the desktop shortcut.
problem only exists for single instance application. normal jnlp application does not have the problem.
need to investigate 2 things:
1. why the incoming new instance will go into the java code ? the native code should be able to detect the single instance too, so it should not get into the java code at all.
2. for the case it needs to get to the java code, if we are still running the same instance, we should not update the cached jnlp file ?
|
Java