Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 84693

Summary: User account creation fails with ClassCastException, unexpected error message
Product: [Retired] Red Hat Web Application Framework Reporter: Oliver Stewart <oliver>
Component: uiAssignee: Jon Orris <jorris>
Status: CLOSED RAWHIDE QA Contact: Jon Orris <jorris>
Severity: high Docs Contact:
Priority: medium    
Version: nightlyCC: cwolfe
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-22 12:48:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Oliver Stewart 2003-02-20 17:00:22 UTC
Description of problem:
Trying to create a new user account at the register/ URL fails with an
unexpected error message to the user and a ClassCastException in the log file
(partial stack trace below).  This is coming from a name collision in FORM_EMAIL
and FORM_LOGIN from ui/login/ (and thus in ParameterModels
that use these constants).  Changing the value of FORM_LOGIN to "login" fixes
the problem.

This bug effectively prevents a new installation of CCM from being used, as no
new accounts can be created.  The Create User page in admin/ uses a widget that
extends UserForm, and thus should display the same behavior.  I think I've seen
this, but can't verify at the moment.

Version-Release number of selected component (if applicable):
5.3.0.AUTO.02.18.2003, 5.3.0.AUTO.02.02.2003

How reproducible:

Steps to Reproduce:
1. Start CCM
2. Load the root node of the CCM site in a browser.
3. Enter a new email address and password and click Submit.
4. On the next screen, click the Submit button.

The error occurs.
Actual results:
2003-02-20 01:28:44,298 [080-2] ERROR dispatcher.BaseDispatcherServlet - error
in BaseDispatcherServlet
java.lang.ClassCastException: java.lang.String
	at com.arsdigita.ui.login.UserForm.validate(
	at com.arsdigita.bebop.FormSection.fireValidate(

Expected results:
The expected behavior was to create a new user account and log that user in,
forwarding to pvt/.

Comment 1 Richard Li 2003-02-20 21:51:58 UTC
What is your primaryUserIdentifier setting in enterprise.init? I cannot
reproduce the problem, either by going to register/ or via the create a new user
admin UI.

Comment 2 Oliver Stewart 2003-02-21 05:05:26 UTC
    primaryUserIdentifier = "email";

Well, the UserNewForm constructor creates a StringParameter as FORM_LOGIN:
        m_loginName = new Hidden(new StringParameter(FORM_LOGIN));

UserNewForm extends UserForm, calling super in the constructor.  The UserForm
creates an EmailParameter as FORM_EMAIL:
        m_email = new TextField(new EmailParameter(FORM_EMAIL));

Neither of those are conditioned on KernelHelper.emailIsPrimaryIdentifier().

So, if FORM_LOGIN and FORM_EMAIL are the same, then there are two parameters in
the same form with the same name.  My debugging showed that m_email was getting
back a String (with the email address) rather than an InternetAddress, which
seems consistent with a name conflict.

Now that I think about it, Bebop should probably throw some kind of exception
when a second parameter with the same name is added to the form, or at least
have a well-defined method of handling overridden form parameters.  Debugging
this sucked.

I'm not sure why you're not getting this.  I don't think the parameters
(ParameterModels/ParameterDatas) are ordered, so maybe you're just happening to
get them in the right order.

Comment 3 Richard Li 2003-02-21 13:02:22 UTC
Crag, I think Oliver is right, although it dismays me that I can't reproduce. If
you agree with the above, we'll apply the patch. I think this is your code...

Comment 4 Richard Li 2003-02-21 14:36:10 UTC
Ah, I understand now. Originally it was different, but we made it the same so
that it wouldn't break the automated GUI tests. Obviously, that doesn't work.
Assigning to jorris to resolve E-tester issue and to fix bug.

Comment 5 Jon Orris 2003-02-21 19:22:00 UTC
I am unable to reproduce this either. As far as I can tell, the issue never
comes up in 2/18 build or the latest one. Could you confirm that your are, in
fact running a clean  2/18 build? 
You reported both 2/18 and 2/2: 5.3.0.AUTO.02.18.2003, 5.3.0.AUTO.02.02.2003

My other point of confusion is that your line numbers in the stack trace don't
make sense. In the 2/18 build, it shouldn't be possible for that exception to
occur there.

The double adding of parameter names, while sketchy and something that will be
fixed, doesn't break the system after a fix made on 2/9. Before then, the issue
you report could come up. 

Currently, the only effect of this double parameter addition is a
ClassCastException on InternetAddress when editing one's user profile. This
defect should be fixed by tonight's build.

Comment 6 Oliver Stewart 2003-02-21 21:35:57 UTC
Erg...sorry about that.  Those were from my file which had debugging comments
added.  The real line number is

Erg again.  It looks like I only updated the ccm-core package, which isn't where
the code I'm running is coming from.  I'll update ccm-core-devel and get back to

Package: ccm-core-devel
Version: 5.3.0.AUTO.02.02.2003-2

Comment 7 Oliver Stewart 2003-02-21 22:21:30 UTC
Weird.  I just did a clean install of 2.18, and now I'm getting a CCE in the
other direction:

java.lang.ClassCastException: javax.mail.internet.InternetAddress
	at com.arsdigita.ui.login.UserForm.validate(
	at com.arsdigita.bebop.FormSection.fireValidate(

This was from a different action, BTW.  This time I was editing my profile at

I think the code in ui/login/ (line 284) is incorrect. 
m_email's parameter value should be an InternetAddress, not a String.

The specific behavior previously reported in this bug does seem to work for me
now.  I think the problem still exists, though.  It seems to be simply a matter
of chance (or JDK implementation/host architecture - e.g. I'm running on a
BigEndian machine) whether or not, or where, this problem manifests itself. 
There still are two differently typed parameters under one name in the same form.

Comment 8 Oliver Stewart 2003-02-21 22:41:48 UTC
Duh...You already mentioned the edit-profile ClassCastException.

I still think that the code in ui/login/ (line 284) is incorrect. 
m_email.getValue(state) should always return an InternetAddress.

Comment 9 Richard Li 2003-08-22 12:48:52 UTC
should be fixed on the tip; some cleanups here removed some of the bebop
pagestate witchcraft