Red Hat Bugzilla – Bug 84693
User account creation fails with ClassCastException, unexpected error message
Last modified: 2007-04-18 12:51:25 EDT
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
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):
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.
2003-02-20 01:28:44,298 [080-2] ERROR dispatcher.BaseDispatcherServlet - error
The expected behavior was to create a new user account and log that user in,
forwarding to pvt/.
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
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
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.
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...
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.
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
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.
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
Weird. I just did a clean install of 2.18, and now I'm getting a CCE in the
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.
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.
should be fixed on the tip; some cleanups here removed some of the bebop