4.7.5 -> 4.8.0 Java

Hi!
What is the procedure for migration from Jre8 to Jdk11 for windows server?
This link is correct? Java Downloads | Oracle
Stop Openfire, uninstall jre8, install jdk21, upgrade Openfire - correct?

I’d like to know this as well. Though my server is CentOS 7. I run # java -version and it says:
openjdk version “11.0.13” 2021-10-19 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.13+8-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.13+8-LTS, mixed mode, sharing)
And when I run sudo rpm -Uvf openfire-4.8.0-1.noarch.rpm I get:
error: Failed dependencies:
java >= 1:11.0.0 is needed by openfire-4.8.0-1.noarch

Any advice?

Getting the JRE requirement right within the Openfire RPM has been a source of trouble. Just install it via rpm -Uvh --nodeps openfire...rpm

Updated the server, everything works, thanks to the developers :+1:

The updated worked fine for me as well, but the unsatisfied dependency remains for the package manager.

Running transaction check
ERROR with transaction check vs depsolve:
java >= 1:11.0.0 is needed by (installed) openfire-4.8.0-1.noarch
** Found 1 pre-existing rpmdb problem(s), ‘yum check’ output follows:
openfire-4.8.0-1.noarch has missing requires of java >= (‘1’, ‘11.0.0’, None)

The openfire RPM packages specifies package dependency as following:

Requires: java >= 1:11.0.0

checking the versions provided by java-11-openjdk package no “java” version tag is provided:

> rpm -qp --provides java-11-openjdk-11.0.21.0.9-1.el7_9.x86_64.rpm
java-11 = 1:11.0.21.0.9-1.el7_9
java-11-openjdk = 1:11.0.21.0.9-1.el7_9
java-11-openjdk(x86-64) = 1:11.0.21.0.9-1.el7_9
jre-11 = 1:11.0.21.0.9-1.el7_9
jre-11-openjdk = 1:11.0.21.0.9-1.el7_9

Running the same command for java-1.8.0-openjdk package the version tag “java” exists:

> rpm -qp --provides java-1.8.0-openjdk-1.8.0.392.b08-2.el7_9.x86_64.rpm
java = 1:1.8.0.392.b08-2.el7_9
java-1.8.0 = 1:1.8.0.392.b08-2.el7_9
java-1.8.0-openjdk = 1:1.8.0.392.b08-2.el7_9
java-1.8.0-openjdk(x86-64) = 1:1.8.0.392.b08-2.el7_9
java-fonts = 1:1.8.0.392.b08
java-openjdk = 1:1.8.0.392.b08-2.el7_9
jre = 1:1.8.0.392.b08-2.el7_9
jre-1.8.0 = 1:1.8.0.392.b08-2.el7_9
jre-1.8.0-openjdk = 1:1.8.0.392.b08-2.el7_9
jre-openjdk = 1:1.8.0.392.b08-2.el7_9

To fix the problem I think it is sufficient to change openfire.spec as following:

Requires: java-11 >= 1:11.0.0

I think you need to install the java-11-openjdk-headless package, which satisfies Openfire

For me it also applies for the headless package java-11-openjdk-headless which doesn’t provide any “java”. This is why I faced the problem during upgrade/installation and had to ignore dependencies with --nodeps.

> rpm -qp --provides java-11-openjdk-headless-11.0.21.0.9-1.el7_9.x86_64.rpm
java-11-headless = 1:11.0.21.0.9-1.el7_9
java-11-openjdk-headless = 1:11.0.21.0.9-1.el7_9
java-11-openjdk-headless(x86-64) = 1:11.0.21.0.9-1.el7_9
jre-11-headless = 1:11.0.21.0.9-1.el7_9
jre-11-openjdk-headless = 1:11.0.21.0.9-1.el7_9

I think this is RHEL7 issue as on RHEL9

dnf whatprovides java-11
...
java-11-openjdk-1:11.0.17.0.1-0.2.ea.el9.x86_64 : OpenJDK 11 Runtime Environment
Repo        : appstream
Matched from:
Provide    : java-11 = 1:11.0.17.0.1-0.2.ea.el9

Good morning everyone, I hope you are well, I want to share the solution to the problem, you must install the jdk-11 package, with that you will be able to install version 4.8.1, then the console only runs on localhost, so They will have to change so that you have remote access in the installation. I hope this helps you. You can write anything to me. I use Centos7

Just a little additional thing for @geosolares comment on only accessing the setup panel via localhost, one suggestion made within the IgniteRealtime MUC by @zoidberg was using SSH port forwarding to forward port 80 to your device, and then connect through the SSH tunnel, this allows you to configure Openfire securely through the web interface, and then you should likely reverse proxy it after forwarding port 443 to whatever port you configured the web interface to be on.

Hope that helps :slight_smile:

Edit: “Forwarding” is a bad word to describe this, as it implies packet forwarding while reverse proxy proxies, but I couldn’t think of a better word to use to describe it.