java.lang.NoClassDefFoundError: org/jboss/cache/TreeCache

[vovik1]

The problem is very simple (I?d even say just stupid).


I am getting (JBoss 4.0.3SP1)

19:24:02,671 ERROR [[/ivms]] StandardWrapper.Throwable

java.lang.NoClassDefFoundError: org/jboss/cache/TreeCache

at com.nextone.bn.common.DBCacheManager.createCache(DBCacheManager.java:61)

I?ve copied jboss-cache.jar from server\all\lib to server\default\lib since we deploy in ?default? and even (out of desperation) explicitly added absolute path of the jboss-cache.jar to JBOSS_CLASSPATH in run.bat

Nothing helps? I also tried to put jboss-cache.jar in several different places inside our .ear

Still no luck.

It seems that class loader cannot find it anyhow.

Please, help.

Vladi.

[brian.stansberry]

Hi Vladi,

I suspect the class def it can't find *isn't* org.jboss.cache.TreeCache, but rather some other class that TreeCache uses. One of my favorite java quirks is the fact that a NoClassDefFoundError tells you the class it was trying to initialize when it couldn't find a class, rather than the missing class itself.

Did you copy over jgroups.jar as well?

[vovik1]

Hi Brian,
Thanks for your reply.

I've thought about that. I did copy jgroups.jar there (default/lib).
Should I copy something else?

Vladi.

[brian.stansberry]

jboss-cache.jar and jgroups.jar should be all you need; all other JBossCache dependencies are already on the classpath in the default config.

Suggest you try the following (I just did this and it worked fine):

1) Remove any JBOSS_CLASSPATH tweaks you may have done; get JBoss into its standard state except you've got jboss-cache.jar and jgroups.jar in default/lib.

2) Copy the tc5-cluster-service.xml file from all/deploy to default/deploy. This file starts the TreeCache we use for HttpSession replication. You don't need it, but if it deploys correctly we know that a cache instance can be started.

3) Remove your ear (so we can get a clean picture).

4) Start JBoss. If the tree cache starts cleanly, we know the needed classes are on the classpath. If then your app still has a problem, there is something odd with the classloading configuration of your ear.

[vovik1]

Brian,
Thanks so much.
I did what you said and it started working!!!

I guess the problem was in the order of my actions.
I copied jboss-cache.jar
It didn't work, so I explicitly added jboss-cache.jar to the JBOSS_CLASSPATH

It didn't work either, so I copied over jgroups.jar (by the way, I don't think there is a documentation about it. I just guessed)
Then, it didn't work again.

Only removing jboss-cache.jar from the JBOSS_CLASSPATH did the trick.
(this last attempt I haven't done, I mostly tried to copy other .jars and to different places).
The real problem here is (I guess): Why does loader complain about TreeCache class when it misses something else. I am sure that standard JVM loader (at least 1.4 JVM) does not do that (I've been through it ones).

Any way, thanks a lot.
I really appreciate it!

Vladi.

[brian.stansberry]

Glad it worked; hadn't really thought through why the JBOSS_CLASSPATH setting would be a problem, but experience has taught me to start with a clean setup :)

I see now why it would be a problem -- jars loaded via JBOSS_CLASSPATH are in a parent classloader to those loaded from default/lib. If you loaded jboss-cache.jar from JBOSS_CLASSPATH and jgroups.jar from default/lib, the classloader that loaded jboss-cache.jar would not be able to see jgroups.jar.

The real problem here is (I guess): Why does loader complain about TreeCache class when it misses something else. I am sure that standard JVM loader (at least 1.4 JVM) does not do that (I've been through it ones).

That's interesting. I've seen this kind of problem many times, but honestly can't recall if it was always in JBoss. If I get a chance I'll check it out.

(If anyone in the community wants to look into whether this misleading message is a JBoss issue and finds that it is, please write a test case and create a JIRA issue. Please search JIRA first in case there is an existing issue).