Upgrade from x86 to x64 Windows in 4.3.0 Admin page issue

Lord_Cochise · January 14, 2019, 9:34pm

Been using Openfire since the 1.x days, this current install was a clean setup from about 4.0.x on Windows, x86 version. Have kept using the x86 version since the x64 migration steps never seemed to work right in previous versions.

SO this is an attempt to update from x86 to x64, 4.2.3 to 4.3.0. I’m using AD and SQL Server, using a custom subdomain and a Let’s Encrypt ssl cert. Attempted to copy the current install folder from C:\Program Files (x86) to C:\Program Files; x64 installer did see it and appear to upgrade ok, but afterwards could not get into Admin page, and clients did not connect. Re-attempted later but kept the C:\Program Files (x86) path with similar results BUT the clients reconnected immediately, same issues with admin page. I’m guessing there must have been path issues in a config file somewhere that moving to C:\Program Files broke, but whatevs.

Uninstalling the x86 version and installing the x64 version over it didn’t work w/o the bundled java version, so I used the openfire_4_3_0_bundledJRE_x64.exe installer.

SO, the current issue is the admin page produces the following (at https://subdomain.domain.com:9091/index.jsp, redacted) which was the link for the 4.2.3 page. I’m guessing I should either (1) toggle setup and reconfigure (2) install java over itself (3) something else?

HTTP ERROR 500
Problem accessing /index.jsp. Reason:

Server Error

Caused by:
java.lang.NoClassDefFoundError: com/sun/syndication/fetcher/FeedFetcher
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getDeclaredConstructor(Unknown Source)
at org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2655)
at org.eclipse.jetty.servlet.ServletContextHandler$Context.createServlet(ServletContextHandler.java:1372)
at org.eclipse.jetty.servlet.ServletHolder.newInstance(ServletHolder.java:1297)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:647)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:519)
at org.eclipse.jetty.servlet.ServletHolder.prepare(ServletHolder.java:803)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:530)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:503)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: com.sun.syndication.fetcher.FeedFetcher
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:565)
at java.lang.ClassLoader.loadClass(Unknown Source)
… 45 more
Caused by:
java.lang.ClassNotFoundException: com.sun.syndication.fetcher.FeedFetcher
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:565)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getDeclaredConstructor(Unknown Source)
at org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2655)
at org.eclipse.jetty.servlet.ServletContextHandler$Context.createServlet(ServletContextHandler.java:1372)
at org.eclipse.jetty.servlet.ServletHolder.newInstance(ServletHolder.java:1297)
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:647)
at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:519)
at org.eclipse.jetty.servlet.ServletHolder.prepare(ServletHolder.java:803)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:530)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:503)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305)
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
at java.lang.Thread.run(Unknown Source)

EDIT -> Solution found in earlier thread (Issues after Openfire 4.3.0 Beta update). Just stop service, delete or move C:\Program Files/openfire/plugins/admin/webapp/WEB-INF/lib folder and restart service.

wroot · January 15, 2019, 10:55am

Moving folders probably have issues with paths. So, if you really want to move installation folder to not x86 Program files, then doing clean install and then moving some files from the older installation is the better way, or just leave it in x86 folder

It didn’t work without the bundled JRE as your current JRE was 32-bit. You could just install 64-bit Java on your system and it should have worked. But using bundled version is just easier in my opinion.

So, i guess everything is fine now? That issues with left over lib folder is not easily reproducable on clean installs. I guess happens more when changing archs (x86 to x64).

Lord_Cochise · January 15, 2019, 1:04pm

The version of 4.2.3 I had installed was the x86 bundle originally, so I imagine it uninstalled together, yes. I had issues in previous versions where I had a discrete java install that would update independently. I did try a clean install and move folders from the x86 folder, service started but nothing could connect, whereas a x64 clean install over the x86 folder path DID, so I’m just going to leave it that way until the next patch release comes out, probably.

Essentially yes, everything appears fine just with the lib folder removal. Would be nice if the installer could detect and automatically move relevant files from an x86 install to the new path w/o having to do it manually, but not a huge deal.