Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 83513 invoked from network); 27 Nov 2002 09:24:44 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Nov 2002 09:24:44 -0000 Received: (qmail 1119 invoked by uid 97); 27 Nov 2002 09:25:27 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 1094 invoked by uid 97); 27 Nov 2002 09:25:26 -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 1082 invoked by uid 98); 27 Nov 2002 09:25:25 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <20021127092409.44249.qmail@web20601.mail.yahoo.com> Date: Wed, 27 Nov 2002 09:24:09 +0000 (GMT) From: =?iso-8859-1?q?Stephen=20Riek?= Subject: Re: Tomcat Filter with RequestDispatcher - IncompatibleClassChangeError To: Tomcat Users List In-Reply-To: <20021127072923.55727.qmail@web20604.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1744555871-1038389049=:43887" 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 --0-1744555871-1038389049=:43887 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Ok, after further investigating, I realize I must have screwed up my Tomcat installation somewhere along the line because a Request Dispatcher that worked several months ago no longer works and give the same errors below. Based on this, I can rule out the Filter code being wrong and turn my attention to stuff I recently added. The prime suspect as always is the xml libraries. Would this affect it ? I hate the fact that adding JAXP to my system breaks some Tomcat things. Recently I added JAXP which means that I now have in /common/lib, - activation.jar - dom.jar - jaxp-api.jar - jdbc2_0_stdext.jar - jndi.jar - jta.jar - ldap.jar - mail.jar - mysql.jar - naming-common.jar - naming-resources.jar - sax.jar - servlet.jar - tools.jar - tyrex-0.9.7.0.jar - xalan.jar - xercesImpl.jar - xsltc.jar and in /jasper I have, - crimson.jar - jasper-compiler.jar - jaxp.jar In order to install JAXP I had to remove 'jaxp-api.jar' from /jasper Could any of this be the cause, or should I really look at just reinstalling the latest stable version of Tomcat4 ? If it helps, my classpath includes, commons-beanutils.jar; (jakarta) commons-collections.jar; (jakarta) jakarta-oro-2.0.6.jar; (jakarta) commons-digester.jar; (jakarta) commons-logging.jar; (jakarta) velocity-J2EE-dep-1.3-rc1.jar; activation.jar; (javamail) mail.jar; (javamail) \common\lib\servlet.jar; dom.jar; (jaxp) jaxp-api.jar; (jaxp) sax.jar; (jaxp) xalan.jar; (jaxp) xercesImpl.jar; (jaxp) xsltc.jar; (jaxp) turbine-2.2-b2-dev.jar; (jetspeed) jetspeed-1.4b1.jar; (jetspeed) ecs-1.4.1.jar; (jetspeed) but things in the classpath shouldn't affect Tomcat, I think. Stephen Stephen Riek wrote: Thanks for the reply, Craig. > > Error Trace > > ----------- > > > > java.lang.IncompatibleClassChangeError > > This exception normally means you have made a change in a superclass and > recompiled it, but not recompiled a subclass that depends on the old APIs. mmmmm, I have no idea which class this could be referring to then, unless it means one of Tomcat's distribution classes. To further debug, I removed ALL other classes under "WEB-INF/classes", so that I only have my one Filter there. I also removed all jars from WEB-INF/lib, then restarted Tomcat. Therefore, the only superclass involved is the Filter class. I recompiled my LanguageFilter.java and yet the error still occured. > > at mas.TestFilter.doFilter(Store/LanguageFilter.java:35) > > What is "Store"? Is that supposed to be the package name? Sorry, yes, I copied an earlier/older trace. > You should recompile *all* your classes to catch any cases > where you've made incompatible changes. I've done exactly that now (basically due to the fact that I only have the ONE class - the LanguageFilter.java) I have even deleted the entire contents of the "/work" directory and restarted Tomcat again to ensure that it is not an old class being cached in memory. Interestingly, the very first time that I make a request to the Filter, I get the following error message: java.lang.LinkageError: Class javax/servlet/RequestDispatcher violates loader constraints at test.LanguageFilter.doFilter(test/LanguageFilter.java:36) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) Yet when I hit "reload" the error message changes to: java.lang.IncompatibleClassChangeError at test.LanguageFilter.doFilter(test/LanguageFilter.java:36) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2366) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) These error messages were created with this Filter code and I've added the check you suggested in your earlier reply. package test; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public final class LanguageFilter implements Filter { private FilterConfig filterConfig = null; public void init(FilterConfig filterConfig) { this.filterConfig = filterConfig; } public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String servletPath = ((HttpServletRequest) request).getServletPath(); // If the first element is '/en/' or '/fr/' : if (servletPath.indexOf("/en/") == 0 || servletPath.indexOf("/fr/") == 0) { String lang = servletPath.substring(1,3); request.setAttribute("lang", lang); String targetURL = servletPath.substring(3); System.out.println(targetURL); RequestDispatcher rd = null; ServletContext sc = this.filterConfig.getServletContext(); rd = sc.getRequestDispatcher(targetURL); System.out.println("ok, RequestDispatcher created"); if (rd!=null) { rd.forward(request, response); } return; } // No language match, so just handle the request as normal. chain.doFilter(request, response); } public void destroy() { } } It works fine for URLs that do not start with /en/ or /fr/ so it really does seem to be a RequestDispatcher and not Filter problem. Stephen. --------------------------------- With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs --------------------------------- With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs --0-1744555871-1038389049=:43887--