Bug 84693 - User account creation fails with ClassCastException, unexpected error message
Summary: User account creation fails with ClassCastException, unexpected error message
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: ui   
(Show other bugs)
Version: nightly
Hardware: powerpc
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jon Orris
QA Contact: Jon Orris
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-20 17:00 UTC by Oliver Stewart
Modified: 2007-04-18 16:51 UTC (History)
1 user (show)

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: ---


Attachments (Terms of Use)

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


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