How I can force updating of my jar files when client open applet application? Jar files always cached in client machine. And I always need to clear cache using Java Control Panel.
I always need to clear cache using Java Control Panel.
This is probably because the JWS client does not recognize the Jars as being new. One source of such confusion lies in the difference in time-zone between the developers machine and that of the server. In that case, the Jars will typically update within the next 24 hours.
For the purposes of testing, do it outside a browser.
If your problem is that old versions of the files are present after redeploying new versions, then consider having a form of timestamps or build numbers in your jar file names.
This will require you to update your JNLP file for every deployment, but your cache problems should go away. It did for us.
Version your jars in your applet tag with each build / deploy. This will force a reload.
ARCHIVE="foo-1.0.16.jar" > ARCHIVE="foo-1.0.17.jar"
Related
I'm trying to save/load images in the resource/public/images folder of my spring boot project, but I faced a problem that all changes to this folder require to restart of the tomcat server but I need to implement all changes without restarting anything to avoid production problems.
I searched for a solution on the Internet and I reached to use additional tools that should be a solution to my problem so I used devtool dependency but I still have the problem.
I'm not looking for local changes on my IDE but I need a solution that can be work everywhere.
First of all the solution that you are looking for is not possible and should not be design like that. Think of it, when your application would be ready, it would be a jar/war (an archived library) deployed on production and its not expected that your jar/war has to have changed at runtime. The correct solution would be, on the same server where you would deploy you app, you can create a folder (may be in same directory where you place your jar) and in this folder you can manage your images and can be read from there. So try by creating a folder outside your app.
And for your local, devtool is basically consume the latest changes from code and helpful only for development as you don't want to restart the server every time when you make any changes in the code.
I have an application that has an applet that does two simple things:
Download an executable jar file from our server (if the user doesn't already have it) to an specific folder in the user's PC
Execute the jar file with the corresponding parameters
This jar file monitors an Office file for changes and send it back to our server.
The problem is the war Chrome is creating with Java with this NPAPI thing. So I have until September to think of an alternate technology or stop the Chrome support.
Do you think of some other way to achieve the same result? Just download and execute. Doesn't seem that hard =(. Can HTML 5 do that?
EDIT
I was looking into Java Web Start and became a little happy. It appears that it can do what I want: executing a up to date jar file passing parameters. But I never worked with JWS, so I have some doubts:
Is it possible to pass parameters to it? I read about some JSP files that you can configure to do that, but I'm still unsure.
Theoretically, it should start automatically from a browser link, am I right? I tried this site:
https://docs.oracle.com/javase/tutorial/deployment/webstart/running.html
and it didn't work that way. I had to mark "always open files of that type" on Google Chrome. Is there a way for automatize it?
Thanks again!!
From what I know there are at least two things that allow you to stick with Java.
Webstart
Install4
Webstart is provided by Oracle and allows you to download Java program from the web and execute them. Update mechanisms exist, so you can always provide a current version.
Install4J (or any other installer for Java applications that offers an update mechanism) provides an installer which enables your customer to install an application which afterwards will be kept up to date by the integrated update mechanism. But Install4J comes at a price, there might be freeware / open source alternatives. Install4J and its alternatives are often discussed here on SO, you might want to check here.
I think the FileAPI of HTML5 is limited and can not access arbitrary files because a sandbox prevents this. You might check SO again for details about that.
My company produces Java Applications for Servers and delivers JNLP files to start local Applications. Since OSX 10.8.4 it is required to sign JNLP files with a Developer ID to keep Gatekeeper happy (it's actually in the release notes at the very bottom).
The question is: how to accomplish this? AFAIK you can sign Apps (we have some Java Apps signed with Developer IDs) - but JNLP - Files are just that: files.
Next: how to do this with generated JNLP files. We have to modify them as they come from a server - e.g. properties, base URL and so forth.
AFAIK Java has a certain mechanism to say JNLP files are signed via their respective JAR file (the one that holds the main class) - but: Jar files are signed with a different certificate they will not satisfy Gatekeeper as well.
I did find one reference on how to sign tools and stuff, but it does not apply the scenario of dynamic files.
What I do not want as answers: Right-Click and Open to override the Gatekeeper or change the System- or Java settings. This is not an option.
[UPDATE]
Since OSX 10.9.5 you also have to sign using OSX 10.9+ and have valid version 2 signatures. How will this be done?
I think I found a solution. The only one I can currently think up. We basically need to wrap the JNLP with a custom app launcher, sign the app, make sure we can modify the JNLP on the fly on a server and then have it run.
As you may be aware, there is an app bundler project which can wrap up any JAR files into an OSX executable. This can be signed, delivered and will not fail Gatekeeper. I made a custom fork (which is up for a pull int o the main fork) that can take an JNLP file, wrap it up and you have a custom application doing just all the stuff a JNLP should do.
A Requirement is, however, that you do have a valid "Developer ID Application" certificate
Head over to bitbucket.org and download the current version
Run the ant task and build the appbundler package.
Have a look at the documentation for an example build script that will create the app container.
The example does not include the JNLP into the application right now.
The applications signature is created in a way so that the JNLP file can be modified later.
The application is being put into a zip file. This is important for downloading an application since they are only directories
Create your server code. Load the ZIP file, put the JNLP File into the directory <yourapp>.app/Contents/Java/
Deliver the zip file.
Now, if everything went fine, the zip file should automatically be unpacked in the Download folder and you should see your application icon. If you really made no mistake, you can execute the application as if it was a normal one.
I hope this will help a lot of developers fixing the broken JNLP behavior with OSX.
[UPDATE for modifiable JNLPs]
Since OSX 10.9.5 it is required to have valid version 2 signatures on your app. This means that it the trick that was previously used by the app bundler (set a resource list file) does not work anymore. Everything and anything has to be signed now and it is virtually impossible to change the signed app afterwards.
I did however find a way: Use the app bundler. Set the JNLP to a file inside the Contents/_CodeSignature directory. Do not yet copy your modifiable JNLP in there but do this e.g. using Java later on when patching the zip (you'll need some code here anyway).
Please note: this should really only be needed if you have to put another JNLP file dynamically into the app container (thats is what the questions was about)
UPDATE (08-2017)
Oracle will be releasing Java 9 by the end of September. The appbundler does not handle the java9 vm correctly. They changed a whole lot of the API and the way that javaws works. For I need to say: stick with java8 if you want to use wrapped JNLP apps.
We've been able to determine that you can sign a jnlp file with codesign, using the "Developer ID Application" Certificate, like this:
codesign -f -s "Developer ID Application: " foo.jnlp
The result from this operation seems to pass Gatekeeper on the local machine. However, it seems like the signature gets stored as extended HFS attributes, and as a result, it is not transmitted if a user fetches the file from a HTTP transaction.
It might work if you took the .jnlp file, and packaged it in some kind of container, like a .dmg or maybe a .tar.gz, however, that's both a lot of work, and it provides a fairly challenging user experience.
From an email thread with Apple tech support, it seems the official word is to use the xip tool to work around the reliance on HFS extended attributes with codesign:
Instead of codesign, use xip (pronounced "chip")
to create a signed archive of your JNLP file. Provide your Developer
ID Installer identity as the argument to the --sign option, not your
Developer ID Application identity.
A xip archive is essentially a signed zip archive so it can be served
over the Internet in the same way as a zip archive. It will be
unarchived automatically on the client Mac.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/xip.1.html
From my experimentation the xip tool always generates an archive with the jnlp contained in a folder when unxip'd.
Just to summarise the discussion; currently there is no existing solution on how to come around this.
This means that end users cannot launch an application via JNLP easily. Basically one needs to tell the user to Right-Click and Open to override the Gatekeeper.
The other solution would be to make an signed Mac application and have users install that via disk image.
Would it work to bundle a simple executable shell script called something like "myapp" in a signed .dmg which looks like this:
javaws http://path/to/my/app.jnlp
that way you can change the .jnlp however you like without changing your .dmg. I don't have an Apple Developer ID, so I can't try it myself right now.
I have a swing application that is installed in the server, and to access it, I have created a short-cut in every computer in the network, and it's working just fine. The application uses jrxml files to generate documents, and they are packaged in a folder called Cycloplan and its working fine, but I still have some technical issues, in which every time I make some updates in the configuration files, I have to go to every computer and paste the Cycloplan folder to it, so I am looking for a method to avoid this operation when an update shows up. please help.
Package the .jrxml files into Jars and deploy the lot using Java Web Start. They will be updated automatically when the Jar is updated.
Some users are complaining that the applet no longer works, When they view the java console they are greeted with a java.lang.noClassDefFoundError and checking my access log's I see they have downloaded the jar file that contains the class, and then issue a get request for the particular class.
Different users break on different classes.
Some users are fine.
Any ideas what could cause this/fix this.
I have checked to make sure the file is in their java cache, cleared the cache etc. nothing seems to fix them.
If they hit a qa site it breaks as well.
The jar is getting corrupted in transit, We are looking at getting patches from oracle/bea for the server.
It appears that if a connection is too slow (Modem speeds) that weblogic will signal the end of a transfer by sending a packet with len=0.
The network will signal java saying the download completed successfully and then java fails with a java.lang.noClassDefFoundError.
This can occur if the class itself can be loaded but some dependency of that class cannot be. Are there external JARs that are dependencies?
Are you sure the jar file contains all the necessary classes? Open it up in your favorite Zip application and double check. Maybe a recent build of that jar got messed up and doesn't have everything in it.
I'm assuming that you have made some updates by your wording. It is highly likely that some users have a previous Jar file cached.
When deploying a new applet version in a live configuration I perform the following:
Ensure the page holding the applet is not cached - use HTTP no-caching techniques. You may want to redeploy from a new page with these headers to ensure that it's not the case.
Deploy the jar file from a different URL for each update (I encode the version number in a directory, but you can equally rename the jar file).
If applet performs any client server interaction ensure that you check version numbers and report incorrect version to the user.
Even if you follow this the user may still have a problem, ask them to try these one at a time (listed in order they should try):
Press refresh on the browser window.
Restart all browser windows
Uninstall all Java VMs found on "Add/Remove programmes" and reinstall latest Java (yes, they must do this at their own risk!)