We (the people at my company) have created an application for Tomcat that uses servlets and jsp's as a GUI a while ago.
We've just now finished an update where one of those jsp's is heavily altered. But when we replace the war file on one computer, it keeps using the old jsp (of which all traces were deleted from said computer) whereas it works perfectly everywhere else.
The problem persists even after the computer was restarted.
Has anyone ever seen such behaviour? What can be done about it?
This may be because of the caching. First of all make confirm that the project is cleaned properly. and check the html of the page if the page contains old code or the latest one if old code is there then browser is getting the old files so try to clear the cache of your browser and then try to execute.
how to cleare cache firefox chrome
Does deleting all traces also imply a "clean" on the server? You probably know that it keeps some classes(especially compiled jsps) in the "work" folder
The problem very likely is caused by timestamp mismatch. The newly uploaded JSP page or servlet has an older timestamp than that of the cached page or servlet on the server. To avoid the problem, ensure the system clock on the machine where the JSP or servlet uploaded from is in sync with the system clock of the machine where the server is running on. To remedy the problem, check the following:
• Make sure the file transfer client (like winscp known to cause problem) date, time and time zone is in sync with the Apache Tomcat server.
• Verify the JSP date, time and time zone is up to date with the Apache Tomcat server. If not, re-deploy the JSP with the correct timestamp.
• If updating the JSP timestamp failed, the last thing you want to do is to remove the JSP in Apache Tomcat work directory if you don’t have important sessions to keep.
Stop the server.
Delete webapps/APP_NAME folder
Replace webapps/APP_NAME.war with the new one.
Start the server.
this should help :)
I had the same problem but it wasn't the tomcat.
My Apache was set to allow browsercaching for text/html and text/plain types for 1 month.
The call of that page was made per JavaScript and even if you reload the page with Ctrl+F5 those JavaScript calls are still loaded from the browsercache.
After clearing the browsercache i got the right page.
From now on i don't enable browsercaching for those types in apache anymore.
The problem persists even after the computer was restarted.
If you've deleted the JSPs, then the problem has to be compiled JSPs in the work directory tree. Take off and nuke them from orbit :-)
Related
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.
Why we can see change made on jsp on refreshing the page?
why we have to restart the server in case of any changes made in servlet?
what is the difference between both?
Servlets are pre compiled class files but jsp will compile at runtime only. And we have jasper listener for jsp it will notify the server when ever we are changing the jsp then server will replace old class file with new one. That's why jsp changes are reflected immediately.
Servlets are compiled classes we burry somewhere under WEB-INF but it copies them to its base working location to run them. Until they are changed at THAT location, the changes won't reflect and it does that only at a server restart.
In case of a jsp page When Tomcat is asked to execute a JSP, is compares the modification date of the JSP file with the modification time of the compiled class corresponding to this JSP, and if more recent, it recompiles on the fly before executing it.
The other answers stand correct, however you asked "why do we have to restart the server?" You do not. You just need the server to utilize the updated file rather than pulling from the cache. There are multiple ways to do this. For Tomcat 8.0.21, it seems true that saving a change in web.xml leads the server to use the files rather than the cache.
The quickest way I found to do this was to add a space, save, remove the space, save again. Also, I did it within a significant area such as within the url-pattern tags.
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"
This was a question about testing file upload functionality using a local java server on Windows 7 platform. Since the question evolved with Marko's input, I have edited it, so that those who run into the same challenge do not waste time on evolution details and reach conclusions sooner.
The challenge was to direct uploaded file to a folder outside of the WAR structure and successfully read it from there. For example: upload an image into c:/tmp/ and then redirect to a confirmation page that displays the image <img src="c:/tmp/test.jpg" />. The upload worked but image would not be displayed. And based on Marko's input, this makes sense because browser sitting at localhost will refuse to load anything from local disk structure using c:. Maybe these are security considerations similar to those with file input control where we cannot set a default path...
The following tag will work in a locally created .html file but when pasted into a jsp, it won't work. And the difference is that browser uses localhost to get to the jsp.
<img src="c:/tmp/test.jpg" />
Solutions
I think that Marko's answer pretty much defines what needs to be done. While I didn't go with that approach, it clearly is the better way to do it and I will accept that as the answer. Thanks, Marko!
For those who don't want to bother installing a Web server and are willing to live with a bit of a hack, here's what I have done. Again, I didn't want to upload files into my WAR structure because I would then need to remember about clearing that folder before deploying to the server. But that upload folder still needs to be accessible, so I simply created another dummy project and put that upload folder under its WebContent. This works for the purposes of my local testing. The only nuisance is that after uploading a file, I need to refresh the dummy project's WebContent in Eclipse.
config.properties
#for uploading files
fileUploadDirectory=C:/javawork/modelsite/tmp/WebContent
#for building html links
publicFileServicePrefix=http://localhost:8080/tmp
<img src="http://localhost:8080/tmp/test.jpg" /> // this works - tmp is the name of my dummy project.
If you are citing literally the HTML that goes to the browser (the one that you access via "vieew source") then this has nothing to do with Java. The browser is the one who interprets these links. If they fail to load, the problem is in the browser/file system.
UPDATE
According to the results of your additional diagnostics, I conclude that the browser (sensibly!) refuses to load anything from your local disk if it is referenced from an HTML file coming from an internet URL, even when that URL is localhost.
UPDATE 2
(Deleted, irrelevant)
UPDATE 3
However you handle the files uploaded to the server, it's definitely not going to look like your solution -- the file is on the server's local filesystem, not client's. This sort of thing can be handled at the Apache HTTP server level -- reserve an URL section for static content and configure Apache with a base directory from which to serve the static content. Even if you run the server locally, on the same machine where you test it, you still need to go through the network interface.
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!)