NullPointerExceptions in catalina.log during startup

Help / Discuss
#1

It seems to be more of a cosmetical issue, is not new according to my logs, and does not seem to trigger any actual misbehaviour.

However, after a Tomcat restart, is see tons of NullPointerExceptions in my catalina.log:

[2023-11-14 19:14:18] [info] 2023-11-14 19:14:18,301 [main] ERROR DefaultExtensionLicenseManager - Failed to load license file at [null]
[2023-11-14 19:14:18] [info] java.lang.NullPointerException: Cannot invoke "java.net.URL.getPath()" because "licenseUrl" is null
[2023-11-14 19:14:18] [info] #011at org.xwiki.extension.internal.DefaultExtensionLicenseManager.initialize(DefaultExtensionLicenseManager.java:94)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:365)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:451)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:201)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.getDependencyInstance(EmbeddableComponentManager.java:406)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:355)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:451)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:201)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:189)
[2023-11-14 19:14:18] [info] #011at org.xwiki.extension.repository.internal.local.LocalExtensionStorage.<init>(LocalExtensionStorage.java:91)
[2023-11-14 19:14:18] [info] #011at org.xwiki.extension.repository.internal.local.DefaultLocalExtensionRepository.initialize(DefaultLocalExtensionRepository.java:100)
[2023-11-14 19:14:18] [info] #011at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39)

Is this supposed to happen?

Xwiki is 14.10.19, Debian Bookworm/Bullseye, Tomcat 9, Debian packages

#2

It’s generally safe to assume that a NullPointerException is not expected.

This error is very strange, it’s not really clear to me how it’s possible. Do you have any error or warning before that in the log ?

Which version of Java are you using (the error suggest it’s Java 17 or more) ? No problem was reported with Java 17, but it was not tested much with Java 21 yet AFAIK.

This specific nullpointer won’t have any bad consequence other than the log, but it might be the sign that there is a more serious root cause.

#3

I’m hitting this issue as well, with Java 17. I’m wondering if this could be due to Loading... since I’m running Tomcat 9.0.70. I wish I could give a try to a distinct version of Tomcat but on Ubuntu mantic I can’t figure how to downgrade to for instance Tomcat9 9.0.58 which is available in Ubuntu jammy: after adding the jammy apt sources list and running apt update it seems apt search won’t find version 9.0.58-1ubuntu0.1 while it’s listed in jammy. Probably a misuse of apt by me…

#4

Downgrading to a Tomcat9 version lower than 9.0.70 fixed the issue for me. I downgraded because at the time of writing there’s no more recent Tomcat9 package available for the distribution I’m using (Ubuntu).

I managed to downgrade on Ubuntu as 23.10 follows:

Add Ubuntu 22.04 repositories apt sources

/etc/apt/sources.list

deb http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse

deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted universe multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted universe multiverse

Run downgrade commands

sudo apt-get install -t jammy tomcat9=9.0.58-1ubuntu0.1
sudo apt-get install -t jammy tomcat9-common=9.0.58-1ubuntu0.1
sudo apt-get install -t jammy libtomcat9-java=9.0.58-1ubuntu0.1

There’s probably a single command which performs the three updates directly though.

#5

Indeed, I just noticed it on Ubuntu – Package Search Results -- tomcat9. That’s not great…

Strangely, the last stable Debian distribution with tomcat9 (Debian 11/bullseye) stopped at 9.0.43 (they did upgrade to 9.0.70 on the unstable branch, which is probably why Ubuntu has it, but it never ended up in Debian 12).

I just reported Bug #2044495 “Upgrade tomcat9 to a version greater than 9.0.70” : Bugs : tomcat9 package : Ubuntu.

Also added a note on Tomcat Installation (XWiki.org).

#6

Sorry for the delayed feedback, I was “under water” the last few weeks.

Side note: In Ubuntu, Tomcat is only contained in universe, so to my knowledge is not covered by official security updates. Keep this in mind if you run it on a server.

I’m running Debian 12 “Bookworm”, but with Bullseye (Debian 11) repos also entabled to get a security supported Tomcat version for Xwiki. I’ll probably switch to the new Xwiki-Jetty-packages soon now that they are available, but have not migrated yet.

I just listed the involved packages to provide feedback here and noticed something interesting:

root@XXX:~# dpkg -l | egrep 'tomcat|openjdk'
ii  libtomcat9-java                      9.0.70-2                                all          Apache Tomcat 9 - Servlet and JSP engine -- core libraries
ii  openjdk-11-jre-headless:amd64        11.0.21+9-1~deb11u1                     amd64        OpenJDK Java runtime, using Hotspot JIT (headless)
ii  openjdk-17-jre:amd64                 17.0.9+9-1~deb12u1                      amd64        OpenJDK Java runtime, using Hotspot JIT
ii  openjdk-17-jre-headless:amd64        17.0.9+9-1~deb12u1                      amd64        OpenJDK Java runtime, using Hotspot JIT (headless)
ii  tomcat9                              9.0.43-2~deb11u9                        all          Apache Tomcat 9 - Servlet and JSP engine
ii  tomcat9-common                       9.0.43-2~deb11u9                        all          Apache Tomcat 9 - Servlet and JSP engine -- common files
ii  xwiki-tomcat9-common                 14.10.19                                all          XWiki is a free wiki software platform written in Java with a design emphasis
ii  xwiki-tomcat9-mariadb                14.10.19                                all          XWiki is a free wiki software platform written in Java with a design emphasis
root@XXX:~#

(Note that openjdk-11 is installed as the Xwiki packages depend on it, but openjdk-17 is the used version.)

So actually libtomcat9-java, which seems to provide the much of Tomcat 9’s core, still seems to be included in and shipped with Debian Bookworm in version 9.0.70, while some parts (tomcat9-common) were discontinued and are only available in Bullseye and version 9.0.43.

Strangely, the last stable Debian distribution with tomcat9 (Debian 11/bullseye) stopped at 9.0.43

That’s not strange, at all.

Version 9.0.43, released in January 2021, was probably the current version when Bullseye was frozen (hard freeze in March 2021), and once the distribution is released, the packages are not updated any more except in really exceptional circumstances. Any security related and critical bugfixes are backported into the package versions included in the distribution to avoid unwanted disruptions / breakages in running installations. For most packages this works fine, for others which outdate faster and where you you don’t rely that much on stability, there’s the -updates repositories, where some packages are provided in more recent versions indeed. If you go even further, you have to resort to the Backports repositories, which I would not really recommend for servers.

Other Linux distributions take exactly the same or very similar approaches.

As we see here with Tomcat 9.0.70, and there were also other “stable” Tomcat 9 releases with critical regressions, we can see that’s warranted. :wink:

To get back on topic, the thing with libtomcat9-java in Bookworm is peculiar, though.

In any case, my Tomcat indeed reports itself as 9.0.70, and also libapr it uses got updated:

[2023-09-21 19:05:22] [info] Server version name:   Apache Tomcat/9.0.43 (Debian)
[2023-09-21 19:05:22] [info] Server version number: 9.0.43.0
[2023-09-21 19:05:22] [info] Loaded Apache Tomcat Native library [1.2.26] using APR version [1.7.0].
(...)
[2023-11-14 18:50:11] [info] Server version number: 9.0.70.0
[2023-11-14 18:50:11] [info] Loaded Apache Tomcat Native library [1.2.35] using APR version [1.7.2].

I don’t see any misbehaviour of the running Xwiki application, though.

#7

Ok, if I understand Loading... correctly, I would

  • either need to dowgrade to Tomcat 9.0.43 from Debian Bullseye,
  • or open an issue against Tomcat 9.0.70 libraries in Debian Bookworm and hope for a backport, right?

(BTW, Links to Xwiki Jira seem to be broken here… At least for me it only displays “Loading…” except of the issue key or additional information:

image

)