ClassFormatError in PluginManager.java on first start - Wildfire 3.1.1

Hi,

I just tried to install wildfire 3.1.1 on a debian stable system running sun’'s java 1.5.0_07.

The process starts up fine after a ./wildfire start and keeps running. However it does not bind to a port and it prints the following error message to wildifire/logs/error.log every 20 seconds:

2006.11.04 14:28:39 org.jivesoftware.wildfire.container.PluginManager.loadPlugin(PluginManager.java: 467) Error loading plugin

java.lang.ClassFormatError: Illegal field name "

" in class org/mortbay/util/Container

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:620)

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)

at java.net.URLClassLoader.access$100(URLClassLoader.java:56)

at java.net.URLClassLoader$1.run(URLClassLoader.java:195)

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

at java.net.URLClassLoader.findClass(URLClassLoader.java:188)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:620)

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)

at java.net.URLClassLoader.access$100(URLClassLoader.java:56)

at java.net.URLClassLoader$1.run(URLClassLoader.java:195)

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

at java.net.URLClassLoader.findClass(URLClassLoader.java:188)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

at java.lang.Class.getDeclaredConstructors0(Native Method)

at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)

at java.lang.Class.getConstructor0(Class.java:2640)

at java.lang.Class.newInstance0(Class.java:321)

at java.lang.Class.newInstance(Class.java:303)

at org.jivesoftware.wildfire.container.PluginManager.loadPlugin(PluginManager.java :347)

at org.jivesoftware.wildfire.container.PluginManager.access$200(PluginManager.java :49)

at org.jivesoftware.wildfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:907)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)

at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:65)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:142)

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:166)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:595)

Any ideas?

Thanks.

H. Mueller

one more addition,

I did not install any additional plugins or modified any configuration files.

This happens with a vanilla wildfire 3.1.1 extracted to /opt/wildfire.

Bye

H. Mueller

run “java -version” to make sure it’'s picking up the correct jvm

any chance the box already had a jvm installed on it that the wildfired script is picking up before 1.5?

you can also try modifying the startup script use a specific java location vs looping through the common ones.

-chip

Thanks for the feedback, but I am pretty sure that it is using the correct jvm.

/usr/bin/java -version

java version “1.5.0_07”

Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)

Java HotSpot™ Client VM (build 1.5.0_07-b03, mixed mode, sharing)

I checked and $app_java_home/bin/java evaluates to /usr/bin/java in the wildfire startup script.

Bye

H. Mueller

Wildfire 3.1.1 requires 1.5.0_09. I updated from 1.5.0_07 since I got the same problem as you, and it works fine now.

Hey guys,

Are you using the installers (e.g. .EXE, .RPM) provided in our website or are you installing Wildfire in some other way? We had some issues creating installer for Wildfire 3.1.1 like the one you mentioned in this thread when using some custom build installers. But after using the installers created by our “continuous integration” server they disappeared. The problem that you mentioned appeared right after the initial setup was completed. A simple restart of the server fixes the problem. It seems to be related with the pack200 uncompression logic.

Regards,

– Gato

ok,

updating to java 1.5.0_09 solved the issue.

thanks a lot

H. Mueller

dombiak_gaston wrote:

Are you using the installers (e.g. .EXE, .RPM) provided in our website or are you installing Wildfire in some other way?

I used the tarball.