tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Riek <stephenr...@yahoo.co.uk>
Subject Re: Tomcat Filter with RequestDispatcher - IncompatibleClassChangeError
Date Wed, 27 Nov 2002 09:24:09 GMT

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 <tomcat>/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 <tomcat>/jasper I have,
- crimson.jar
- jasper-compiler.jar
- jaxp.jar
In order to install JAXP I had to remove 'jaxp-api.jar' from <tomcat>/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)
<tomcat_home>\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 <stephenriek@yahoo.co.uk> 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

Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message