|Summary:||User account creation fails with ClassCastException, unexpected error message|
|Product:||[Retired] Red Hat Web Application Framework||Reporter:||Oliver Stewart <oliver>|
|Component:||ui||Assignee:||Jon Orris <jorris>|
|Status:||CLOSED RAWHIDE||QA Contact:||Jon Orris <jorris>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-08-22 12:48:52 UTC||Type:||---|
|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/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: Always 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 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 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 you. 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(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 http://localhost:8081/register/edit-profile/. 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 22:41:48 UTC
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 12:48:52 UTC
should be fixed on the tip; some cleanups here removed some of the bebop pagestate witchcraft