Hot questions for Using Ubuntu in tomcat8


I have a Spring MVC application running on Tomcat8. Once in a day or two I get an exception in my log file

15-Jun-2016 10:43:39.832 INFO [http-nio-8080-exec-50] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
 java.lang.IllegalArgumentException: Invalid character (CR or LF) found in method name
    at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(
    at org.apache.coyote.http11.AbstractHttp11Processor.process(
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
    at java.util.concurrent.ThreadPoolExecutor.runWorker(
    at java.util.concurrent.ThreadPoolExecutor$
    at org.apache.tomcat.util.threads.TaskThread$

does anybody have an idea what this might be?


This error is caused by malformed HTTP request. In most cases this message is misleading because this error usually happens when you are trying to access unsecured page through https. Tomcat doesn't know that incoming request is encrypted and is trying to interpret this request as plain, unsecured http request.

This is how it could look in logs:

Standard, proper HTTP request (http://localhost:8080)

Received [GET /index.html HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: pl,en-US;q=0.8,en;q=0.6
Cookie: Idea-xxxxx; JSESSIONID=3dxxxxx


HTTPS request (https://localhost:8080)

Received [¹µHÄ;ß!P@<¿


As you can see in second request, there are unknown chars instead of proper HTTP method name (e.g. GET)

So if your server has no SSL configuration and error occurs "once in a day or two", then probably someone is trying to reach your website through https (probably some kind of bot)

Eventually someone is trying to send nonsecured but malformed plain HTTP request (through his own application - bot or other custom client).


I'm trying to set my JRE_HOME variable in catalina.bat to be where my java is stored (/usr/lib/jvm/default-java) in Ubuntu. I edited catalina.bat and added "set JAVA_HOME=/usr/lib/jvm/default-java" at the very top of the file but when I use "./ version" it keeps stating "Using JRE_HOME: /usr". How do I setup my catalina.bat file so that the JRE_HOME will update?

I've tried a few older guides for older versions of Ubuntu but nothing has worked. Any and all help is appreciated I just want to get my computer working for java server side programming. Thanks in advance.


When you starting tomcat using catalina.bat, it searching for file setenv.bat and sourcing it. It is searching in CATALINA_HOME or CATALINA_BASE

So the better way to set JAVA_HOME for the tomcat is:

Create setenv.bat script CATALINA_BASE/bin, if it is not exists already. Add this line to setenv.bat

export JAVA_HOME=/opt/java/jdk1.8.0_05

Make it executable.


I am trying to deploy a .war file using Tomcat8, Apache, and Ubuntu 15.04. When I click "Select WAR file to upload" in the /manager section of tomcat I get the following error:

FAIL - Deploy Upload Failed, Exception: /opt/tomcat/webapps/musicStore.war (Permission denied)

How would I fix this?


Converting comments to an answer, adding more information:

Your /opt/tomcat/webapps directory belongs to someone (execute ls -l /opt/tomcat/webapps to see whom it belongs to).

While tomcat is running, execute ps aux | grep catalina to see which user is running tomcat (depends on the way you start it - might be your own current user). You could chown <thatuser> /opt/tomcat/webapps. However, for production systems I'd strongly recommend to not have the manager application running and tomcat's own directory writeable to itself. It opens up quite a few attack vectors and is bad practice IMHO

If it's a local development system, comfort typically trumps security - and you might opt for keeping the manager app.

To mitigate the potential manager-app problems in production, at least limit access to known IP-Addresses, keep the user database well maintained (not in tomcat-users.xml with clear text passwords). However, on my production systems, tomcat can not write to its own webapps directory - thus hot deployment of applications through the manager app won't work anyways...


I have recently updates my ubuntu deskto to 18.04. After this my tomcat is failing at startup. Each time I restart tomcat using the command service tomcat8 restart the log file give the following error -

    Caused by: java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
    at java.base/
    at java.base/java.util.concurrent.FutureTask.get(
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture.get(
    at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(
    ... 135 more
Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
    at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
    at java.base/java.lang.Class.privateGetDeclaredMethods(
    at java.base/java.lang.Class.getDeclaredMethods(
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperUtilities$
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperUtilities$
    at java.base/ Method)
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperUtilities.secureGetDeclaredMethods(
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperUtilities.getDeclaredMethodWrappers(
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperUtilities.getAllMethodWrappers(
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperUtilities.getAllMethodWrappers(
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperImpl$3.compute(
    at org.glassfish.hk2.utilities.reflection.internal.ClassReflectionHelperImpl$3.compute(
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$
    at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$
    at java.base/

I then installed jdk8 and run update-alternatives command like this -

dimension:bin$ sudo update-alternatives --config javac
There are 2 choices for the alternative javac (providing /usr/bin/javac).

  Selection    Path                                          Priority   Status
  0            /usr/lib/jvm/java-11-openjdk-amd64/bin/javac   1101      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/javac   1101      manual mode
* 2            /usr/lib/jvm/java-8-openjdk-amd64/bin/javac    1081      manual mode

Press <enter> to keep the current choice[*], or type selection number: 
dimension:bin$ sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
  0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1101      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1101      manual mode
* 2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode

Press <enter> to keep the current choice[*], or type selection number:

When I again restarted the tomcat, I saw the same error. Here are the contents to my jvm folder -

ls -lh /usr/lib/jvm/
total 8.0K
lrwxrwxrwx 1 root root   25 Apr  8 18:46 default-java -> java-1.11.0-openjdk-amd64
lrwxrwxrwx 1 root root   21 Aug 24 23:06 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
drwxr-xr-x 9 root root 4.0K Oct  4 10:56 java-11-openjdk-amd64
lrwxrwxrwx 1 root root   20 Oct 28  2016 java-1.8.0-openjdk-amd64 -> java-8-openjdk-amd64
drwxr-xr-x 7 root root 4.0K Oct  4 16:03 java-8-openjdk-amd64

My JAVA_HOME env is currently set to empty.

What should I do to fix my issue.


The java.base part of exception stack trace at java.base/ suggests that you are still running with JDK 11.

Ensure that Tomcat 8 is running with JDK 8. Try debugging the Tomcat startup script with set -x to see how is the Java location determined, maybe it's set in /etc/default/tomcat8?