as you can see in the following log, Openfire opens the port given under “HTTP Binding” -> “Clients can connect to this server using HTTP binding.” even if it is disabled:
We just encountered the same problem. After a DB upgrade, we started Openfire before Confluence, and then Confluence failed to start, because Openfire had taken port 8080. The workaround suggested in the original posting worked, but I agree it seems unfriendly to lock up a port for a disabled featured. Since the feature seems to be disabled by default, how about at least assigning it a less-commonly-used port, e.g. 8482?
I tried looking into this issue and was not able to reproduce it. If you disable httpbind, the system property httpbind.enable is set to false. This prevents the httpBindServer from starting up at openfire startup…
Could you check your system properties to see if that setting is there?
Also, I believe that setting the port to -1 is not sufficent to prevent this…
httpbind.enabled is present and set to false, but this did not prevent the port from being acquired at startup. The following stack might help:
[org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:95)] Error starting HTTP bind service
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:2 11)
at org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.jav a:309)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.Server.doStart(Server.java:228)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:92)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startHTTPBindListeners(Conn ectionManagerImpl.java:505)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionMa nagerImpl.java:134)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManage rImpl.java:52)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(Connecti onManagerImpl.java:106)
at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginMa nager.java:507)
at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java :46)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:985)
Our Openfire server has not been updated in quite awhile (version 3.4.1), so maybe the issue has been fixed in the version you were testing.