[GLASSFISH-20672] Deploying new version of ear with components with new version numbers caches javaws to break due to caching in java 7 update 21 Created: 28/Jun/13  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gcruscoe Assignee: michael.y.chen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 7u21


Tags: app-client, appclient, cache, java, java7, java_7, java_web_start

 Description   

When we switched to Java 7 update 21 from Java 7 update 17 we noticed that the apps that we run with Java Web Start started to fail to start after a new deployment of the same app with a different version number.

It seems the auto-generated jnlp files are referencing a full path to the component (including the version) and when it gets a 404 (because the file can now be found under the very similar url with just the build number different).

It seems this could be a bug with Java 7 update 21 or an issue with what files are being cached because of the Java Web Start on glassfish 3.1.2.2.

I could not find any bug for Java or glassfish for this.

Example Deploy
Eample-ear-1.0.1
which contains the client app
Example-app-1.0.1

Run the JavaWS app
javaws https://ourserver.ourdomain:8181/ExampleApp
Success!

Then make a new build and deploy
Example-ear-1.0.2
which includes
Example-app-1.0.2

And run
javaws https://ourserver.ourdomain:8181/ExampleApp

And we get a file not found for something like:

https://ourserver.ourdomain:8181/___JWSappclient/xxxx/xxxxx/xxxxx/Example-app-1.0.1/xxxx/xxxxx

Please let me know if you need any more information.


Generated at Mon May 04 03:13:58 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.