We have been getting java.lang.ClassFormatError: Truncated class file since yesterday for our Zimbra server based on Ubuntu.
Despite that nothing is changed; everything had been going well until yesterday. Now the web user interface of Zimbra is not rendered; we get 500 internal server error in Firebug.
Any ideas to solve this problem?
Your server is setup on default configuration.
It unpacked your war file into the system temp directory, likely /tmp.
Some other process then cleared out the /tmp/ directory, rendering your active runtime invalid.
See other answer about setting temp / work directories for more information.
Related
I'd like for my webapp which is deployed as a war ROOT.war to have write access to /var/www/html/static/images so that it can write uploaded and converted images to that folder so nginx can serve it statically. Currently it doesn't work and triggers a java.nio.file.FileSystemException exception together with the Filesystem is read-only message.
But the filesystem is not read-only and is in great condition. The folder has already been chmodded 777.
Extra info:
The tomcat setup is running on an Ubuntu 18.04 Azure VM with managed disk. The folder is residing on an Ext4 formatted drive
Let's start with: chmod 777 is great for testing, but absolutely unfit for the real world and you shouldn't get used to this setting. Rather set the owner/group correctly, before you give world write permissions.
Edit: A similar question just came up on the Tomcat mailing list, and Emmanuel Bourg pointed out that Debian Tomcat is sandboxed by systemd. Read your /usr/share/doc/tomcat9/README.Debian which contains this paragraph:
Tomcat is sandboxed by systemd and only has write access to the
following directories:
/var/lib/tomcat9/conf/Catalina (actually /etc/tomcat9/Catalina)
/var/lib/tomcat9/logs (actually /var/log/tomcat9)
/var/lib/tomcat9/webapps
/var/lib/tomcat9/work (actually /var/cache/tomcat9)
If write access to other directories is required the service settings
have to be overridden. This is done by creating an override.conf file
in /etc/systemd/system/tomcat9.service.d/ containing:
[Service]
ReadWritePaths=/path/to/the/directory/
The service has to be restarted afterward with:
systemctl daemon-reload
systemctl restart tomcat9
Edit 2022: Note that these are the 2019 paths - validate the file locations for later versions. From the comments to this answer (thank you to V H and Ng Sek Long) here are some updates:
In current Ubuntu file is here: sudo vi /etc/systemd/system/multi-user.target.wants/tomcat9.service – V H Feb 26, 2022 at 19:55
Mine (Ubuntu 20) is installed here /lib/systemd/system/tomcat9.service smh everybody use a different path. – Ng Sek Long Mar 28, 2022 at 8:36
End of edit, continuing with the passage that didn't solve OP's problem, but should stay in:
If - all things tested - Tomcat should have write access to that directory, but doesn't have it, the error message points me to an assumption: Could it be that
Tomcat is running as root?
The directory is mounted through NFS?
The default configuration for NFS is that root has no permissions whatsoever on that external filesystem (or was it no write-permission? this is ancient historical memory - look up "NFS root squash" to get the full story)
If this is a condition that matches what you are running, you should stop running Tomcat as root, and rather run it as an unprivileged user. Then you can set the permissions on the directory in question to be writeable by your tomcat-user, and readable by nginx, and you're done.
Running Tomcat as root is a recipe for disaster: You don't want a process that's available from the internet to run as root.
If these conditions don't meet your configuration: Elaborate on the configuration. I'd still stand by this description for others who might find this question/answer later.
I tried to install confluence on my own ubuntu server, but always failed. The error is:
com.atlassian.util.concurrent.LazyReference$InitializationException: java.lang.IllegalStateException: Spring Application context has not been set
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:149)
caused by: java.lang.IllegalStateException: Spring Application context has not been set
at com.atlassian.spring.container.SpringContainerContext.getComponent(SpringContainerContext.java:48)
I saw some solutions in the jira confluence forum saying try to fix the permission of installed directory and home directory. I tried but failed again. How can I fix the problem.
In my case the issue was corrupted confluence.cfg.xml file (contains DB connection stings and other settings). The file size was 0 bytes.
I would suggest to use a VM to create a new installation and borrow confluence.cfg.xml from that installation.
It's embarrassing that this behavior has been allowed to exist for nearly 7 years in a commercial product. This is a basic stuff...
I wish that was on instructions somewhere:
Make single backup copy of confluence.cfg.xml immediately before any writes to it by the application. Application should be able to restore from backed up copy if it gets corrupted.
Atlassian documentation lists the following causes of this problem:
The user running Confluence does not have write permissions to the home folder defined in <install>/confluence/WEB-INF/classes/confluence-init.properties or the install directory.
You are running Confluence as the root user or if you have an application firewall enabled (SeLinux or AppArmor).
The database driver is not located in the <install>/confluence/WEB-INF/lib folder or you are using a database version that is incompatible with the bundled driver.
The hostname of the server can not be resolved.
In my case I was running it as root user inside docker container.
I need help figuring out why a couple of my web applications are intermittently throwing 404 errors when trying to bring up a JSP. One of them has the JSP accessed directly and the other has a servlet that is forwarding to a JSP. The pages work most of the time, but occasionally will throw a 404. If the user refreshes their browser 1-3 times, the page starts working again without any changes required.
Here is a sample of the error as seen in the web browser (Chrome):
type: Status report
message: /app_root/my_page.jsp
description: The requested resource is not available
The problem seems to be related to recompiling the JSP pages. The .war file and expanded directory haven't changed. There are always three errors in the logs that correspond to each 404 error:
WARNING: Failed to delete generated class file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.class]
May 19, 2015 6:32:24 AM org.apache.jasper.compiler.Compiler removeGeneratedFiles
WARNING: Failed to delete generated Java file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.java]
May 19, 2015 6:32:24 AM org.apache.jasper.compiler.Compiler generateJava
WARNING: Failed to delete generated Java file [D:\Apache Software Foundation\Tomcat 7.0\work\Catalina\localhost\app_root\org\apache\jsp\my_005fpage_jsp.java]
I'm running Java 1.7 on Tomcat 7.0.53. Tomcat is running on a Windows 2008 R2 server.
Here is what I've tried so far, based on the information I've found from google. However, the 404's continue.
Disabled Windows indexing on the entire Tomcat directory
Turned off development mode in my production environment
Increased modificationTestInterval in my QA environment from the default (4 seconds) to 3600 (1 hour) [Note: it is currently set to 0 to try to help me reproduce the issue]
Changed the owner on the Tomcat work directory to be the same id as the id that the service is running as.
I am in the process of getting anti-virus turned off on the work directory to see if that helps.
While this issue is occurring on my prod and QA servers, it doesn't occur for me on my local Tomcat instance. In fact, I have yet to see the problem from my workstation even when running the QA and Prod applications. The issue has only been seen by other people.
The Tomcat container caches .java and .class files generated by the JSP parser, which are used by the web application. Sometimes these get corrupted or cannot be found. This may occur after a patch or upgrade that contains modifications to JSPs.
Solution is to just simply delete the work directory and restart the tomcat
I had the same problem after deploying a .war on our live server. These are the steps that I followed to solve the problem:
1) Shut down the tomcat server
2) Go to <your tomcat directory> -> work -> Catalina -> localhost -> <your project> -> org -> apache -> jsp ->
3) Manually delete both .class and .java
4) Delete the .war file and the deployed folder from the website that is having the issue on the webapps folder.
5) Export a new .war, and put it into the webapps folder.
6) Start up the tomcat service again.
Once the server is finished deploying, it will auto re-generate the deleted files in the "work" directory and the website should be available again without the intermittent 404 error.
I hope it works for you too.
Check the authority of this file or folder. Generally this problem is caused by lack of access to folders.
domino version 9.0.1
designer version 9.0.1
(I changed the text of the stack trace slightly to take the customer out of the picture.)
Every once in a while in a developmental environment, I have been getting the following stacktrace in the server log:
> 7.01.2014 17:01:13 HTTP JVM: com.ibm.designer.domino.napi.NotesAPIException: File access error:
> Error while getting information on item $FileData
> 17.01.2014 17:01:13 HTTP JVM: Note item not found. For more detailed information, please consult error-log-0.xml located in
> c:/Domino/data/domino/workspace/logs
> 17.01.2014 17:01:13 HTTP JVM: Managedbean DatabaseController could not be created Can't instantiate class:
> 'de.holistic.cust.epr.EprDatabaseController'..
> java.lang.ClassNotFoundException: class
> java.lang.ClassNotFoundException:
> de.holistic.cust.epr.EprDatabaseController. For more de
> 17.01.2014 17:01:13 HTTP JVM: ailed information, please consult error-log-0.xml located in c:/Domino/data/domino/workspace/logs
> 17.01.2014 17:01:13 HTTP JVM: com.ibm.xsp.webapp.FacesServlet$ExtendedServletException:
> com.ibm.xsp.exception.EvaluationExceptionEx: Error while executing
> JavaScript computed expression
the following from the xml log file does not show any of the promised extra information
com.ibm.designer.domino.napi.NotesAPIException: File access error: Error while getting information on item $FileData Note item not found
This exception is also sometimes coupled with a SecurityException.
1. Resigning the database does not do anything
2. changing the classes and xpages and resaving sometimes fixed the issue once, or it was just the time it took me to try that
3. restarting the HTTP task / server never makes a differance
4. cleaning and building does not do a thing.
After google searching for the issue, some people have had this issue while storing their java classes in the java area of the "normal designer" perspective. I have my java code in a custom source folder "WebContent/WEB-INF/src".
Is anyone else having/had this issue? If so, how can it be best resolved? Is this a bug in the XPage implementation? I have not had this issue with java classes in a jar file, only when the source code needs to be compiled. Although it is a possibility to deliver the application with jar files instead of raw classes, it is impractical in a developmental setting. Any help would be greatly appreciated.
The compiled java class is stored in the $FileData item of the design note in which the java source is saved. So the error means the compiled code is lost and not generated by the server. Below are something that I think might help to debug this issue.
Open the project view in designer, modify the filter to show the java classes to check if they are available.
Check if the java source folder is on the build path.
Check the auto-rebuild option.
If the development is on local and deployed to the server via design refresh or replace. Check if the classes are lost in this process.
I'm using Tomcat and PHP5 with JavaBridge. I have bridged PHP and Java so I can screencap web pages within PHP. This was working on another server but after moving to a new server I can not get it working, so I'm reaching for straws here.
require_once("http://localhost:8080/JavaBridge/java/Java.inc");
java_autoload("/web/sites/madfrog/domain.com/cron/bin/html2image.jar");
$JavaHTML2Image = new Java("com.elance.proposal.html2image.client.MainBridge");
It should have loaded all of the project html2image.jar when the script _autoloaded it, however when you create the new Java object I get the error
Class Not Found: Fatal error: Uncaught [[o:Exception]:"java.lang.Exception: CreateInstance failed: new com.elance.proposal.html2image.client.MainBridge. Cause: java.lang.ClassNotFoundException: com.elance.proposal.html2image.client.MainBridge
I asked the guys over in Java and they said I needed to put the jar file in the lib so Java could find it, so I dumped it into Tomcat's webapps folder an into /usr/share/java. But that did nothing. With that said the PHP has a direct reference to it, so it should be loaded.
I'm at a lost after two days. any help is appreciated!
Which version of Tomcat do you use?
For Tomcat 6 or Tomcat 7 put the jar either in ${tomcat.home}/lib or in ${tomcat.home}/webapps/${your.war}/lib
While tomcat.home is your tomcat installation directory. And your.war is the name of your war file.