JBoss has a long history of using funky non-standard classloaders. It
has burned many folks in the past and since the classloaders are not
standard classloaders, it hard to debug the issue at times. The
easiest thing I can recommend is that you use TCP transport to connect
to your brokers. Hopefully the serialization that this forces will
fixe your classloading issues.
On 8/1/06, Nguyen Kien Trung <[EMAIL PROTECTED]> wrote:
Thanks, James for the prompt reply.
You're right about the classloader. In my third log.debug(), I tried to
compare classloader of two classes (whose types look the same)
And it returns FALSE. It means, there's a difference in classloader.
I'm not quite familiar with classloader stuff, so let's me explain my
package deployment so that you could help me to figure out.
I deploy in JBoss 4.0.4.GA as war files, each war file contains Core.jar
(which has all model classes - classes that i'm talking above regarding
the error) and Lingo.jar
[FrontEnd.war]
||
|| ActiveMQ
||
[Manager.war]
||
|| ActiveMQ
||
[Module.war]
There are 2 things which may be important to consider
1) When i switch to JBossMQ, then things are going just fine.
2) The error occurs randomly - not for particular method in the proxy object
3) When I try to debug - timing delay - then there's no error
>> log.debug("equal class loader ==? : " +
>> (m.getParameterTypes()[0].getClassLoader() ==
>> invocation.getParameterTypes()[0].getClassLoader())); // return false
--
Regards,
Hiram
Blog: http://hiramchirino.com
