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/.
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.
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.
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 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.
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
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.
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 pagestate witchcraft