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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] > Superclass is class com.inmezzo.authn.logon.Logon > Superclass package is package com.inmezzo.authn.logon > New object is [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]