powered by Jive Software

Upgrade from 3.3.0 to 3.3.1 error during setup

Hi all,

Can I get a little light shed on an issue? I upgraded our server from 3.3.0 to 3.3.1 by following the “brief” upgrade guide, and now I get the following error message during setup. Any suggestions as to where I begin to fix this???

Thanks in advance.




Caused by:


at org.jivesoftware.util.JiveGlobals.deleteXMLProperty(JiveGlobals.java:492)

at org.jivesoftware.openfire.admin.setup.setup_002dprofile_002dsettings_jsp._jspSe rvice(setup_002dprofile_002dsettings_jsp.java:75)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1074)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:146)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:285)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)

at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765 )

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:627)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

Powered by Jetty://

Update to this post:

Interestingly enough, when I run Openfire the manual way using /opt/openfire/bin/openfire.sh the server launches and everything works beautifully. BUT…when I use the automated approach of /etc/init.d/openfire the server starts but I’'m required to walk through the setup process again, at which point I get to the embedded database question and then setup fails.

Does anyone have any suggestions or ideas as to why it’'s forcing me through the setup process, and how can I tell the openfire script not to require me to run through the setup?



it seems that the new startup script fails to set the right OPENFIRE_HOME directory for whatever reason.

Or you are using root instead of user jive to start Openfire and this works as some permissions are wrong.


Thanks for the information. You were right on target. It was attempting to launch from the default 3.3.1 location and run as the “daemon” user. After I edited /etc/sysconfig/openfire to point to the existing /opt/openfire home_dir and change the run user to “root” it worked. I’'m concerned about running as “root” so if there is something I need to do such as to create another user I would like to do it. Are there any special privs needed for this user to launch and run Openfire? A how-to would be nice also.

Thanks for the help!!!


/opt/openfire should be owned by “jive” or any other user. So this user should run Openfire. There’'s no need to use “root” to do this as no low-ports are opened.

I did not look at the post_install script which should be in bin/extras but it should do an “adduser” and a “chmod -r” so that /etc/rc.d/init.d/openfire script can do a “su jive -c …” to launch Openfire.


I had the same error here.

I solved the problem by changing th owner of the file /opt/openfire/conf/openfire.xml to jive to make it writeable for the setup process.

The included init script seems to not find the correct locations and ignoring settings made in the sysconfig/openfire file.

short workaround (unclean but working):

In /etc/init.d/openfire I relplaced OPENFIRE_RUN_CMD with


and /opt/openfire/bin/openfire.sh containing:


cd /opt/openfire/bin

/opt/openfire/jre/bin/java -server -Xms32m -Xmx64m -jar …/lib/startup.jar >…/logs/STDOUT.log 2>…/logs/STDERR.log &

Message was edited by: suit4

Hi, I had the same problem.

I figurate that a openfire daemon start up when I turn on the computer(Fedora C6), is that the reason that when i installed openfire i didn’'t have this problem.

So in the command line write:

#ps aux | grep openfire

see what is the PID and kill that procces.

#kill PID

then start openfire from the script:

  1. cd /opt/openfire/bin

  2. ./openfire.sh start

That is all, and it works.

Please, I’‘m newbe on linux, so if someone knows how to stop that the openfire daemon start up when the computer turn on, make me know. (sorry by my english, i’'m latinamerican).

Att: Laura Zapata Aspiazu.