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!)
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.
We have this JAVA webservice that runs on tomcat 9(installed by root).
The webservice creates a generic file log for our client. The problem is only the root user can read and access the file that is being generated.
My question is can I change the output file to be readable for all users by default? (without using chmod everytime the file is generated)
Should it be on code level or configure it on linux?
I have read about this https://docs.oracle.com/javase/tutorial/essential/io/file.html.
But one of our old redhat servers dont have a code level config on its webservice and its working fine.
Thanks
You should not be looking at this from a "java io" side of things.
This is a user permission problem. In other words: probably your tomcat servers shouldn't be running as root in the very first place.
Consider creating a special user that is used to run your tomcat instance. Here you can find guidance how you could do that for an Ubuntu system. And your favorite search engine will for sure know similar links for your favorite Linux distribution, too.
That might also be better from a security perspective: do you really want that people attacking your tomcat ... end up being root on your system if they succeed?!
Long story short: your problem is not some java code within tomcat that writes files; and then other users on your system being unable to access those files. Your problem is that your tomcat service is running as root! Fix the later; and your "initial" problem will be fixed, too.
Final word of warning though: I am not saying that it is easy to change the user setup for you. Maybe it is; but especially if your setup is using "root" for a long time, then there is a certain chance that other things you put in place rely on "being root". So, "not being root" is the right direction; but it might be a painful path to get there, from where you are now.
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.
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"
I have no particular Java knowledge whatsoever. We are running an opensource application which is mainly written in Java. Internet connection dropped while I was editing a job (this is some sort of a translation project management tool) and I cannot open the job anymore.
I checked the database to see if anything is wrong there and all looks fine (I compared values to a working job). Then I logged in to the server and checked logs and seems like this application may be relying on some data which is stored somewhere other than the database.
The log contains tons of lines but I guess this is the one that provides the hint:
ERROR;com.globalsight.everest.workflow.WorkflowProcessAdapter;There is error in create the workflowinstance for the process instance id 54
java.lang.IllegalArgumentException: the userrole value cannot be null
Looks like userrole got messed up while the connection dropped. Now that userrole is not assigned anywhere in the database. I thought I will browse the source files to see where it may be coming from but I am not able to find those. For instance, an exception line says :
com.globalsight.everest.taskmanager.TaskManagerLocal.acceptTask(TaskManagerLocal.java:165)
I browse to that localization and there is a TaskManagerLocal folder there but it is empty. I assume this is compiled in the jar file (right?). Can somebody with Java knowledge shed a light as to how I can dig and find where userrole may be saved and bring by application back up?
Many thanks in advance
com.globalsight... -> globalsight.com
The website states that the sources are on SourceForge
If the project is open source, the code may be packaged inside the JAR file. This is not always the case, as the actual code that is run from the JAR is in compiled bytecode form.
You could try unzipping the JAR using:
jar -xvf the_jar_file.jar
This will create a number of directories/files which may include a src directory. If not, the source is probably not included in the JAR in its un-compiled form, in which case you'd have to download the source from the project site.
Since this error is specifically related to that tool, I'd go to the GlobalSite at http://globalsight.com and ask there. I did a quick search of the site for this error and didn't find anything but you should be able to get some answers (I would think) after posting this on their forum.