I'm experiencing this exception as well. Today I started to test with the v2.4.4 (Tomcat 4.0.1) release. I took my .ear that works perfectly with JBoss 2.4.4 / Tomcat 3.2.3, and am now experiencing issues with this new release.
It seems to be a Class Loader related issue - the class in my app that is reported as violating loader constraints is a Value Object class, an instance of which is returned from a Session Bean method. I've read elsewhere that there maybe potential packaging/scope issues related to this, and I was wondering if anybody has any guidelines?
You mean that this may be a problem with the code itself? And not with the deployment?
I haven't still solved the issue I'm having and I think I'll try with the bundel with the older Tomcat version to see if it works there...
I'm not sure what is the cause of the problem, but it seems that there is a difference in class loading behavior between the Tomcat 3.2.3 package and the Tomcat 4.0.1 package - can anyone else shed any light on this?
One other strange thing :
I've now reverted to using JBoss+Tomcat3.x , and with the app I was trying to deploy (that originated this thread) I don't get the error I was getting with Tomcat4 ...
However, one other app I was running fine in Tomcat4 doesn't deploy in tomcat3.x .. weird ...
I have looked a bit through Tomcat's homepage trying to find out if they had a report on diferences between the two versions but found nothing...
I had the same problem. Everything runs well on Solaris, but gets the problem on Linux. Any update?
I get the same error when I update a class in a EJB jar file then jar/upload it to the JBoss server. When debugging a problem, I have to frequenty upload the changed EJB jar files to the jboss server folder, overwriting the old ones then have the server auto-reload it. When my jsp tries to load the EJB again, I get this error. However if I kill JBoss server and restart it, not changing anything, the new classes load without error.
Its just annoying to have to reload JBoss every time I make a change to a EJB class in a Jar file. I used to not have to do that.