So after some more research and looking at the code for HAPartitionImpl, the ClassNotFoundException must be thrown from within the following block in the handle method:
log.warn("RpcProtocol.Handle(): " + e);
I haven't tracked down the source of the message, but I'm guessing it's the primary key object of the entity whose cache needs to be invalidated. We're using custom pk objects generated by xdoclet, so from my understanding of the JBoss classloading architecture it makes sense that the javagroups util class isn't able to find a classloader for the pk because it's currently being packaged in the same jar as the entity, which is inside an ear that's using a scoped classloader.
I guess there are three options here:
1.) Stop using custom pk objects. In this case it shouldn't have any problems loading from the java.lang package.
2.) Deploy the pks seperately in the server's lib/ dir. I would like our application to be self contained inside the ear, so this isn't ideal.
3.) Stop using a scoped classloader. Not sure about this one.
If anyone has any other ideas, that would be helpful. Thanks.
I've tested out option #2 and that appears to have fixed the problem. But I'd rather go for option #1 as a long-term solution, because it keeps the application self-contained and allows us to hot deploy (wouldn't be possible for #2 because things under /lib are only deployed when the server starts.)
Again, if there's something I'm missing here, it would be great to hear about some other options. Thanks.
I have seen similar problems with classloaders when running JBoss clustered.
I have not been able to test it yet but I think that some fixes were put into JBoss 3.2.2 that may fix your problem.
Yea, I was also hoping that something had gotten checked in for 3.2.2, but the issue still seems to be present in both RC3 and RC4.
Can you construct a sample and attach to a Jira issue so I can re-produce it? You can assign it to me.