Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 55105 invoked from network); 2 May 2002 15:33:05 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 May 2002 15:33:05 -0000 Received: (qmail 28314 invoked by uid 97); 2 May 2002 15:29:26 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@nagoya.betaversion.org Received: (qmail 28201 invoked by alias); 2 May 2002 15:29:25 -0000 Delivered-To: jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 28127 invoked by uid 97); 2 May 2002 15:29:24 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 17073 invoked by uid 98); 2 May 2002 00:30:38 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Content-Type: text/plain; charset="koi8-r" From: Dmitri Lysenko Reply-To: lds@nuix.com.au Organization: DXF Inc./2 To: tomcat-user@jakarta.apache.org Subject: java.lang.VerifyError while using struts with Tomcat 4.0.x Date: Thu, 2 May 2002 10:28:05 +1000 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02050210280500.30552@host51.syd.nuix.com.au> Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, I'm using tomcat 4.0.3 integrated with JBoss 2.4.4 (they run in the same JVM). Struts framework is used to handle the presentation logic. This combination works fine with Tomcat 3.x. However after I upgrated to the Tomcat 4.0.3 I'm experiencing the java.lang.VerifyError (Incompartible argument for a function) while the ActionServlet instanciates some action classes. I'm sure that the problem caused by the changes in the tomcat's classloader. I had the situation when the class with the same name is accessible by two different classloaders. I found out that the problem appears if the class is loaded by the classloader that's different with the one that the current thread uses. In this situation I had this VerifyError. I was able to resolve the problem by eliminating the class duplication, now I have no two same classes that are placed in the different jars. However the question is why this error appears? The situation that I had when the same class is accessible by multiple class loaders is not prohibited by the Java language. I'm wondering what classloader contraint was violated. To fix the problem I have to use the jar's packaging that's not very convenient for me. So I appreciate any help that allows me to resolve this problem in better way. Dmitri Lyssenko, lds@nuix.com.au -- To unsubscribe: For additional commands: Troubles with the list: