tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jane Muse <>
Subject RE: Class cast exception when starting tomcat 7.0.1
Date Thu, 13 Jun 2013 22:44:56 GMT
I'm using the standard implementation of Realm. Here's the code

//Validate passwords
		try {
			if (oldTomcatPassword != null && !"".equals(oldTomcatPassword.trim()))
				TomcatConfig tconf = TomcatConfig.getInstance();
				String digestAlg = tconf.getTomcatPwdEncryptionType();
				String encryptedOldPwd = oldTomcatPassword;
				if (digestAlg != null)
					encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg);
				if (!encryptedOldPwd.equals(tconf.getEncryptedTomcatPwd(tomcatUserName))) {
					errors.add("incorrectPwd", new ActionError("error.password.incorrect"));

As I said, it no longer compiles with catalina.jar from Tomcat 7.0.41. This is not a surprise,
that the signature would change, and I changed the code accordingly. Now it is:

encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType);

Compiles fine now.

. However, when I build with ant, it says actual and formal argument lists differ in length.
I don't know why there's an actual and a formal argument list. I swapped out catalina.jar.

188: error: method Digest in class RealmBase cannot be applied to given types;
    [javac] 				encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType
    [javac] 				                           ^
    [javac]   required: String,String
    [javac]   found: String,String,String
    [javac]   reason: actual and formal argument lists differ in length
    [javac] 2 errors
    [javac] 1 warning

-----Original Message-----
From: Caldarale, Charles R [] 
Sent: Thursday, June 13, 2013 1:41 PM
To: Tomcat Users List
Subject: RE: Class cast exception when starting tomcat 7.0.1

> From: Jane Muse []
> Subject: RE: Class cast exception when starting tomcat 7.0.1

> I had catalina.jar in WEB-INF/lib.

Very, very bad move.

> It's needed because we have an implementation of Realm to store an 
> encrypted tomcat password users enter in the webapp.

Your custom implementation of Realm should be in Tomcat's lib directory, not the webapp's.

Such a Realm should not be tied into the operation of any webapp, other than configuring the
webapp to use it.

> If I remove it and add the catalina.jar from tomcat_home/lib to the 
> classpath

Not sure what you mean by adding it to the classpath; please explain.

> I have to change the signature from
> org.apache.catalina.realm.RealmBase.Digest(String, String) to 
> org.apache.catalina.realm.RealmBase.Digest(String, String, String).

That's because internal Tomcat APIs often change between levels.  You certainly cannot count
on using an older version of Realm with a newer Tomcat (or vice versa).

> Should I not be writing code that needs classes from catalina.jar?

It would certainly be desirable not to be dependent on internal Tomcat classes.  Why do you
think a Realm should be storing a password (encrypted or not) anywhere?  A Realm would normally
be reading a password from some controlled storage, not writing to it.
 - Chuck

for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message