Link to home
Create AccountLog in
Avatar of gagaliya
gagaliya

asked on

java webstart force war download?

Hi we use java webstart to deploy a heavy client (swing gui war file) to the users.  The issue i am having is everytime i make a change to the gui war file, the user will not get the changes until they goto java console and clear the cache, only then java webstart will download a new version of the war to the user's machine.

I know you can change the version to force a redownload, but the version for us is tied up to all sorts of automated deployment process, i dont want to increase the version everytime there is a minor change in the code in development for testing.  

Is there any other way / flag i cant set in jnlp to make java webstart compare the war file size, and if different redownload. Thanks
Avatar of CEHJ
CEHJ
Flag of United Kingdom of Great Britain and Northern Ireland image

I don't think it's necessary to increment version numbers. Updating should be based on the timestamp of the server's JWS jar
Avatar of gagaliya
gagaliya

ASKER

that's not the case, i deployed the new war to the weblogic servers but user's java webstart still using the old war file in their cache, until they go and manually delete the cache, then it will download the new war.
ASKER CERTIFIED SOLUTION
Avatar of Mick Barry
Mick Barry
Flag of Australia image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
> i dont want to increase the version everytime there is a minor change in the code in development for testing.

once you make a change and deploy it, it is actually a different version :)
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Yeah we are doing what the FAQ suggested,  everytime we do a production/staging release we increment the version and this ensures the user redownload the latest version. The problem is the version is autolinked to our cvs tag version in a large shared build script i dont want to modify, so in dev as you continously make changes i dont want to creat a tag everytime there is a small change, it will create a mess in cvs.  

But without creating a new tag, the deployed war version in dev will be the same.  So if you ask the user to hit dev for a quick test, it's a pain in the rear everytime to babystep them through how to manually remove cache first.  

Diff by timestamp is actually perfectly fine for us except it doesnt work, is that a bug in java webstart, not a lot of info on google.  I cant believe after so many iterations java webstart still dont have simple options like compare by bytesize etc... No wonder a lot of people call them unreliable while i was researching this issue.
>>Diff by timestamp is actually perfectly fine for us except it doesnt work, is that a bug in java webstart

That would be a very serious bug. Are you sure the archive in the jnlp is getting its timestamp updated?
you don't want to be using timestamp, especially in a dev environment.

Why are you using jws in your dev environment anyway, far more convenient to just run it directly

> So if you ask the user to hit dev for a quick test

they should be hitting a test server, and you should be creating a new tag for each release candidate deployed to test server.
hi objects, i dont understand your last comment.  How do they run it directly without web start, it's a heavy client not a webpage, to run it directly means to have the desktop team deploy the jar files to the user's pc manually. I think that's the problem webstart was created to resolve.

Users do hit a test dev weblogic server, that hosts the java webstart page/link/wars. Our development cycle is very aggressive due to business requirements, so we are making many changes daily in dev using the same cvs tag,  run it through test cases, get user to test, then kick off the stage build: creates a new cvs tag packaging all the changes in dev, link that to the new war version, then push to stg for uat, and then prod.

If we were to tag every change in dev with a new version, we will be creating 5-10 cvs tags a day. which will be a mess.  Not sure if i misunderstood what you said, but if you have any suggestions on how to improve this process given the aggressive dev env i described, i am very interested to learn to improve our process.  

thank you

> it's a heavy client not a webpage, to run it directly means to have the desktop team deploy the jar files to the user's pc manually

I was referring to developers running it.

> so we are making many changes daily in dev using the same cvs tag

thats fine but once you release it for testing you need to tag it

> If we were to tag every change in dev with a new version, we will be creating 5-10 cvs tags a day. which will be a mess.

Why exactly. Once you release something to test it is a new version.
that way when test finds a problem they can report exactly what version it occurred in.

perhaps you need a different versioning system in testing if tagging is an issue.
>>I think that's the problem webstart was created to resolve.

That's correct.

You need to do some investigation as to why the timestamp is not being used
do not use the timestamp, it will cause you even more issues.
versioning is the way to go, you just need to ensure that each version has its own version number
we do have version number, I guess it comes down to we want webstart to pickup the new war without changing the jnlp war's version number.  Doesnt look like that's possible, many people have the same problems as me when i googled.

One interestig observation is that webstart by default checks for diff/updates, but if this checking process takes too long, it will start the app using the existing cache, while continue to check in the background. The sympton for this is after a new deployment, the first time user startup the app they will still see the old version, but if they close and restart again they will see the new version (assuming webstart finished the diff).  

Anyway doesnt look like there's any solid workaround, i am closing this. Thank you all for your help.
> I guess it comes down to we want webstart to pickup the new war without changing the jnlp war's version number.  Doesnt look like that's possible

You wouldn't want it to :) You don't want it to be downloaded if its the same version.