<< Back to previous view

[JAVASERVERFACES_SPEC_PUBLIC-205] Custom by-class converters not considered in UISelect{One,Many}.validateValue() Created: 10/Aug/06  Updated: 24/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 1.1
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: Macintosh

File Attachments: GZip Archive jsf-api-205.tar.gz     Text File message.txt     File prova2.war     Zip Archive src.zip    
Issue Links:
depends on JAVASERVERFACES_SPEC_PUBLIC-57 Converters - Tied into PropertyResolv... Resolved
Issuezilla Id: 205
Status Whiteboard:

cat2 frame javadoc size_small importance_large

Participants: Ed Burns, rogerk and Ryan Lubke


al80 on ##jsf on freenode found this one, and it appears to be a good candidate
for the upcoming MR.

Look at the javadocs for UISelect{One,Many}.validateValue():

  • Before comparing each option, coerce the
  • option value type to the type of this component's value following
  • the Expression Language coercion rules.

If you have a custom converter installed as a by-type converter, then it will
have been used to convert the value before calling into validateValue().
However, when the EL coercion rules are used, this by-type converter is not

Comment by Ed Burns [ 10/Aug/06 11:38 AM ]

Created an attachment (id=101)
al80's test war

Comment by Ed Burns [ 10/Aug/06 11:39 AM ]

Created an attachment (id=102)
java sources for war

Comment by Ed Burns [ 10/Aug/06 11:40 AM ]

Add jan to CC.

Comment by Ed Burns [ 10/Aug/06 11:43 AM ]

EL Spec section 1.18.7 has this to say about custom coercion.

â–  IfAisnull, returnnull
â–  IfAisassignabletoT, coercequietly
â–  IfAisaString, andThasnoPropertyEditor:
â–  IfAis"", returnnull
â–  Otherwiseerror
â–  IfAisaStringandT'sPropertyEditorthrowsanexception:
â–  IfAis"", returnnull
â–  Otherwise, error
â–  Otherwise, applyT'sPropertyEditor
â–  Otherwise, error

Comment by Ed Burns [ 10/Aug/06 01:56 PM ]

Created an attachment (id=103)
fix for this bug, first iteration

Comment by Ed Burns [ 10/Aug/06 01:57 PM ]

Created an attachment (id=104)
tarball of modified and new files for first iteration bugfix.

Comment by Ed Burns [ 10/Aug/06 01:58 PM ]

Attachment 103 is a JSF Impl based fix for this issue, but I do think something
should be done at the spec level. There is no sense in requiring someone to
write a converter twice: once as a JSF Converter and once as a PropertyEditor.

Comment by Ed Burns [ 11/Aug/06 06:41 PM ]

After thinking about this some more, I have to wonder, why don't we just use
UIInput.getConvertedValue() rather than the EL's coerceToType() in the
UISelect{One,Many}.matchValue() implementation?

Comment by Ed Burns [ 16/Aug/06 01:52 PM ]

take ownership

Comment by Ed Burns [ 24/Aug/06 10:51 AM ]

Let's defer this to 2.0. At least we have a by-type solution in the Sun Impl.

Comment by Ryan Lubke [ 20/Aug/08 12:14 PM ]

57 is an umbrella issue for this one.

Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 07:05 AM ]


Comment by Ed Burns [ 17/Mar/10 02:10 PM ]


Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 12:59 PM ]


Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 02:55 PM ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 12:11 PM ]

Move these to 2.2

Generated at Thu Apr 17 22:04:09 UTC 2014 using JIRA 4.0.2#472.