You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mike Johnson <de...@miketec.org> on 2003/09/24 04:13:15 UTC

Re: Tomcat appears to cause erroneous ClassCastException (see message for circumstances)

You're partially correct thinking this is Tomcat, I believe. The cast
exception can be caused when a class created by a different classloader
is cast in the current one.

In short, try specifying the webapp's classloader when you call
Class.forName(). I believe the forName function defaults to the
application classloader.

>    Object o = aClass.newInstance(); 
>     System.out.println("New object is " + o);
>     System.out.println("New object is a Logon object: " +
>         (o instanceof com.inmezzo.authn.logon.Logon));
>     System.out.flush(); 
>     m_authenticator = (com.inmezzo.authn.logon.Logon) o; // Boom!


On Tue, 2003-09-23 at 09:08, Christopher Williams wrote: 
> I am using Tomcat 5 (I think) as a servlet and web service container via
> JWSDP 1.2.  My OS is Windows XP Professional SP 2.
> 
> I have written a centralized authentication service which uses a pluggable
> authentication module architecture.  Each authentication module derives from
> an abstract base class com.inmezzo.authn.logon.Logon which is contained in a
> JAR file called inMezzo_AuthnLogon.jar, copied to common/lib.  I supply a
> number of authentication modules (Win32, LDAP and others) with the service.
> These are in a package called com.inmezzo.authn.server and are contained in
> a WAR in webapps and they all work fine.
> 
> However, the general pattern is that custom authentication modules will use
> a completely different package hierarchy and will be stored in their own JAR
> files in common/lib.  This, however, causes problems.
> 
> When my web app loads, the following code is executed (note that much of it
> is used simply to provide debug output for this post):
> 
> String aClassName = m_props.getProperty("authenticator",
>     "com.inmezzo.authn.server.NullLogon");
> try
> {
>     Class aClass = Class.forName(aClassName);
>     System.out.println("Class is " + aClass);
>     System.out.println("Class package is " + aClass.getPackage());
>     System.out.println("Classloader is " + aClass.getClassLoader());
>     System.out.println("Superclass is " + aClass.getSuperclass());
>     System.out.println("Superclass package is " +
>         aClass.getSuperclass().getPackage());
>     Object o = aClass.newInstance();
>     System.out.println("New object is " + o);
>     System.out.println("New object is a Logon object: " +
>         (o instanceof com.inmezzo.authn.logon.Logon));
>     System.out.flush();
>     m_authenticator = (com.inmezzo.authn.logon.Logon) o; // Boom!
> }
> catch(Exception e)
> {
>     e.printStackTrace();
> }
> 
> When this code attempts to load a custom authenticator running under Tomcat,
> I get the following output:
> 
> Class is class rdc.users.RIOLogon
> Class package is package rdc.users
> Classloader is StandardClassLoader
> ...
> Superclass is class com.inmezzo.authn.logon.Logon
> Superclass package is package com.inmezzo.authn.logon
> New object is rdc.users.RIOLogon@f34a08
> New object is a Logon object: false
> java.lang.ClassCastException at...
> 
> 
> When, however, I execute the same code from the command line, I get the
> output that I would expect:
> 
> Class is class rdc.users.RIOLogon
> Class package is package rdc.users
> Classloader is sun.misc.Launcher$AppClassLoader@12f6684
> Superclass is class com.inmezzo.authn.logon.Logon
> Superclass package is package com.inmezzo.authn.logon
> New object is rdc.users.RIOLogon@18fb1f7
> New object is a Logon object: true
> 
> 
> Can anybody tell me what the problem is here?  I don't think that I'm trying
> to do anything too perverse.  Is there perhaps a configuration setting for
> Tomcat that will fix this?  Alternatively, can anybody confirm whether it is
> worth my while to rewrite the abstract base class as an interface?  I'm
> loath to do this only to find that it doesn't fix the problem.
> 
> Thanks in advance for any light that you can shed on this matter,
> 
> Chris Williams.
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>