Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0.7 beta
-
None
-
None
-
WSAD 5.1.2
Description
The JSF spec doesn't go into much detail about the way that the
Application needs to search for a converter for a given Object type.
Currently, we only search a Class' direct interfaces and, recursively,
its superclasses for a match. This can be problematic if the
converter definition refers to an interface. The only checking will
be for its direct parents.
Here is an example outlining my problem:
Interfaces:
Descriptor, Active, Identifiable
ModelBase extends Descriptor
Organization extends Active, Identifiable, ModelBase
Classes:
DescriptorImpl implements Descriptor
ModelBaseImpl extends DescriptorImpl implements ModelBase
OrganizationImpl extends ModelBaseImpl implements Organization
This means that if I register my Converter on a Descriptor and a JSF
component needs to find a Converter for an Organization, it will not
find one because the search will go something like this:
Organization = no match
search interfaces: Active = no match
Identifiable = no match
ModelBase = no match
search superclass: null = no match
return null;
Of course, we should just recursively search the interfaces as well.
Preferably, we would want users to be able to define a different
Converter for a Descriptor and an Organization with confidence that
the Organization would always get an OrganizationConverter.
That outlines the bug, which I intend to fix. The real question is
one of strategy.
Here are the strategies we could use:
A: use Class.isAssignableFrom(Class) on each key in the
_converterTypeMap to match the Class to a converter, then get that
converter from the Map. There could be additional algorithms employed
to choose between multiple matches.
B: When checking an interface, we just see if it is present in the
Map. We could execute the internalCreateConverter(Class) method on
it, so that its SuperInterfaces will be searched.