Bug 84693 - User account creation fails with ClassCastException, unexpected error message
User account creation fails with ClassCastException, unexpected error message
Product: Red Hat Web Application Framework
Classification: Retired
Component: ui (Show other bugs)
powerpc Linux
medium Severity high
: ---
: ---
Assigned To: Jon Orris
Jon Orris
Depends On:
  Show dependency treegraph
Reported: 2003-02-20 12:00 EST by Oliver Stewart
Modified: 2007-04-18 12:51 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-22 08:48:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Oliver Stewart 2003-02-20 12:00:22 EST
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/LoginConstants.java (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(UserForm.java:317)
	at com.arsdigita.bebop.FormSection.fireValidate(FormSection.java:328)

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 16:51:58 EST
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 00:05:26 EST
    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 08:02:22 EST
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 09:36:10 EST
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 14:22:00 EST
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 16:35:57 EST
Erg...sorry about that.  Those were from my file which had debugging comments
added.  The real line number is UserForm.java:304.

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 17:21:30 EST
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(UserForm.java:284)
	at com.arsdigita.bebop.FormSection.fireValidate(FormSection.java:328)

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

I think the code in ui/login/UserForm.java#10 (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 17:41:48 EST
Duh...You already mentioned the edit-profile ClassCastException.

I still think that the code in ui/login/UserForm.java#10 (line 284) is incorrect. 
m_email.getValue(state) should always return an InternetAddress.
Comment 9 Richard Li 2003-08-22 08:48:52 EDT
should be fixed on the tip; some cleanups here removed some of the bebop
pagestate witchcraft

Note You need to log in before you can comment on or make changes to this bug.