I'm attempting to deal with the various getter/setter discovery problems
that have been floating around. Among the many, uh, "questionable" passages
I've found, this one strikes me as particularly troublesome:
Class org.exolab.castor.mapping.loader.Types has this method:
/**
* Maps from a primitive Java type to a Java class. Returns the same
class
* if <tt>type</tt> is not a primitive. The following conversion
applies:
* <pre>
* From To
* -------------- ---------------
* Boolean.TYPE Boolean.class
* Byte.TYPE Byte.class
* Character.TYPE Character.class
* Short.TYPE Short.class
* Integer.TYPE Integer.class
* Long.TYPE Long.class
* Float.TYPE Float.class
* Double.TYPE Double.class
* </pre>
*
* @param type The Java type (primitive or not)
* @return A comparable non-primitive Java type
*/
public static Class typeFromPrimitive( Class type )
{
/// Fix for arrays
if ((type != null) && (type.isArray())
&& !type.getComponentType().isPrimitive()) {
return typeFromPrimitive( type.getComponentType() );
}
/// end fix
for ( int i = 0 ; i < _typeInfos.length ; ++i ) {
if ( _typeInfos[ i ].primitive == type )
return _typeInfos[ i ].javaType;
}
return type;
}
It's that "Fix for arrays" bit that�s worrisome. It extracts the basic
component type from an array type, but that's not what the function is
documented to do.
In fact, that change breaks several call-sites that do NOT expect that
behavior. In particular, the findAccessor methods in FieldMolder and
MappingLoader. When trying to find a call-compatable method, such type
transformations are not appropriate and will lead to bad matches.
I've also noticed that the (static) findAccessor methods in FieldMolder and
MappingLoader are an obvious case of copy-and-rape coding gone wrong. The
latter has obviously been (correctly) extended and modified, but the former
has not. I hypothesize that this is leading to some of the problems that we
have seen reported on the list lately.
I'm attempting to refactor the noted repeated/broken code into a single
place in the Types class. I'll submit the patches to the list once things
seem to be working. If I can learn how to write and run test cases I'll
submit those as well.
Along the way I've written some code that applies a basic best-fit algorithm
when looking for accessors, instead of the current first-match approach. I
think this will resolve some of the accessor-not-found problems that arose
in 0.9.3.9
I would love to be contacted off-list by anybody knowledgeable in this code
area.
Todd V. Jonker
Inpath Solutions, LLC
www.inpathsol.com
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
