powered by Jive Software

Openfire 3.3.0 has been released

Openfire 3.3.0 has been released. This is the first release of the server under the new name. The new release includes some new features and important bug fixes. Unlike other releases the upgrade process is going to require some manual processing. It is very important to follow the upgrade steps correctly to ensure a success upgrade. Also note that all plugins need to be updated. Plugins made by third parties will need to be updated too.

Download Openfire from here. The full change log can be found here.

Remember to read the Wildfire to Openfire Upgrade Guide to make sure that the upgrade process is complete.

Openfire Enterprise 3.3.0 has also been released and it now support archiving of group chat conversation. It can be downloaded from the plugins page.

There is also a new beta version of the asterisk plugin. People using the old plugin will need to move to the new beta that besides being compatible with Openfire 3.3.0 it already includes some important fixes. The Red5 plugin will be updated soon as reported by the author.

Enjoy,

Openfire Team

will try to upgrade next Friday, but first i must fix my linux kernel/swap problems…

Ok. Good luck with the linux kernel/swap problems.

Have a happy upgrade.

– Gato

Great work with the new version and with Spark 2.5.1. A few more tests and I am ready to deploy it to my enterprise.

I wish I can get 3.3.0 to work… Straight from the download, it does not work. What else do I need to do to get it to work?

As I stated before. Everyone can login to the server, just no one can see anyone.

Message was edited by: Joeteck

upgrading m test sever with Beta to 3.3.0 (zip version, overwrite)

errors in Launcher:

java.util.zip.ZipError: jzentry == 0,

jzfile = 48621128,

total = 2828,

name = C:\Program Files\Openfire\lib\openfire.jar,

i = 1241,

message = null

at java.util.zip.ZipFile$2.nextElement(Unknown Source)

at java.util.zip.ZipFile$2.nextElement(Unknown Source)

at java.util.jar.JarFile$1.nextElement(Unknown Source)

at java.util.jar.JarFile$1.nextElement(Unknown Source)

at sun.misc.URLClassPath$JarLoader.validIndex(Unknown Source)

at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)

at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source)

at sun.misc.URLClassPath.getResource(Unknown Source)

at java.net.URLClassLoader$1.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(Unknown Source)

at java.lang.ClassLoader.loadClass(Unknown Source)

at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)

at java.lang.ClassLoader.loadClass(Unknown Source)

at java.lang.ClassLoader.loadClassInternal(Unknown Source)

at org.jivesoftware.openfire.starter.JiveClassLoader.(JiveClassLoader.java:44)

at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:88)

at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:49)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)

at com.exe4j.runtime.WinLauncher.main(Unknown Source)

somehow i see errors after W/Ofire upgrades more and more often

Great stuff !

JM-1007 - Occupants in rooms can now be seen from the admin console.

JM-868 - Added favicon to admin console.

and nice fix

JM-897 - Client sessions were not always being counted correctly.

Thanks

upgrading m test sever with Beta to 3.3.0 (zip version, overwrite)” … a little bit late to report problems with the beta version as far as I can tell.

This is not really a problem, but just an observation.

If you install fresh without upgrading and choose the embedded database option, the screen shows “Wildfire” instead of “Openfire” as it takes you through the setup steps.

-dele

… and after installation a wrong Openfire logo is displayed. The login page contains the "openfire™ logo with a lower case “o” while the pages within the admin console contain “Openfire” within the logo. As far as I know the logo itself uses always a lower case “o” while the product name itself uses an uppercase “O” just to confuse everyone.

LG

it2000 wrote:

upgrading m test sever with Beta to 3.3.0 (zip version, overwrite)” … a little bit late to report problems with the beta version as far as I can tell.

this was my bad english i was upgrading my Beta to 3.3.0 final. I’'ve also had errors in Launcher window after upgrading Wildfire 3.2.4 to Openfire 3.3.0 Beta. And i also was able to launch server only after second try.

wroot wrote:

upgrading Wildfire 3.2.4 to Openfire 3.3.0 Beta. And i also was able to launch server only after second try.

wrong again, that was with 3.3.0 Alpha to 3.3.0 Beta. Alpha was installed with installer, then a Beta was extracted from zip version and i’'ve overwrited Alpha version with newer files. And i had errors in Launcher after first launch. Now again.

Is Spark 2.0.8 still compatabile with Openfire 3.3.0?

mruno wrote:

Is Spark 2.0.8 still compatabile with Openfire 3.3.0?

As an XMPP client it MUST be compatible with XMPP server (which Openfire is, no matter the name changes). So the only thing that could be broken it’‘s a non standard features, but i cant think of any that could be related to internal Openfire packages’’ name changes.

I guess I specifically meant Fastpath. Is fastpath 3.3.0 compatible with Spark 2.0.8?

dombiak_gaston wrote:

Have a happy upgrade.

i’'m not happy, Openfire is not working for me. tar.gz package, probably this is openfired issue

old wildfired was working fine.

wildfired, which is working with Wildfire 3.2.3:

#!/bin/sh

export JAVA_HOME=/opt/java/jre

  1. wildfired

  1. chkconfig: 2345 20 80

  2. description: Used to start and stop the wildfire XMPP server

  3. Script used to start wildfire as daemon

  4. The script has currently been tested on Redhat Fedora Core 3,

  5. but should theoretically work on most UNIX like systems

  1. before running this script make sure $WILDFIRE_HOME/bin/wildfire is

  2. executable by the user you want to run wildfire as

  3. (chmod +x $WILDFIRE_HOME/bin/wildfire)

  1. This script should be copied into /etc/init.d and linked into

  2. your default runlevel directory.

  3. You can find your default runlevel directory by typing:

  4. grep default /etc/inittab

  1. Link to the directory like follows

  2. cd /etc/rc.d

  3. ln -s …/init.d/wildfired $90wildfired

  1. Set this to tell this script where wildfire lives

  2. If this is not set the script will look for /opt/wildfire, then /usr/local/wildfire

#export WILDFIRE_HOME=

  1. If there is a different user you would like to run this script as,

  2. change the following line

export WILDFIRE_USER=jive


  1. If a wildfire home variable has not been specified, try to determine it

if ; then

if [ -d “/opt/wildfire” ]; then

WILDFIRE_HOME="/opt/wildfire"

elif [ -d “/usr/local/wildfire” ]; then

WILDFIRE_HOME="/usr/local/wildfire"

else

echo “Could not find Wildfire installation under /opt or /usr/local”

echo “Please specify the Wildfire installation location in environment variable WILDFIRE_HOME”

exit 1

fi

fi

function execCommand() {

OLD_PWD=pwd

cd $WILDFIRE_HOME/bin

CMD="./wildfire $1 >/dev/null"

su -c “$CMD” $WILDFIRE_USER &

cd $OLD_PWD

}

start() {

execCommand “start”

}

stop() {

execCommand “stop”

}

case “$1” in

start)

start

;;

stop)

stop

;;

*)

echo “Usage $0 {start|stop}”

exit 1

esac

exit 0

Wroot,

I had to rerun the redhat-postinstall.sh script located it /opt/openfire/bin/extra/.

I then modified the openfired script as mentioned in my previous thread.

papawu, what do you mean rerun. I’'ve never used that redhat-postinstall script. The tar.gz package was (and i think should) working out of box. What exactly this script does? I could try it out on Monday.

It just copies /opt/openfire/bin/extra/openfired into /etc/rc.d/init.d and runs chkconfig for startup purposes.

I see. Arch doesnt have init.d . I’‘m putting it in rc.d (arch’‘s deamons dir) manually and chmod +x. And add openfired to deamons’’ part in rc.conf (startup thing). It was working with jive-messengerd and wildfired. Except that i had to add JAVA_HOME path, cause it wasnt catching it automaticly.

I cant start server with /opt/openfire/bin/openfire start either. Maybe i should edit/fix this too? Hm, maybe this is because of conf file. Wil try with default one, though i have just added .