One thing I noticed in this area is that the getters and setters are
discovered apparently without respect to their signature. For example I had
two methods in one class called setStartDate, one which expected a
java.util.Date, and another one that took a String.
setStartDate(Date start) { ... }
setStartDate(String start) { ... }
Castor would pick one of them, but that would differ between JVMs, and fail
if it picked the wrong one.
So I ended up having to differentiate the method names by renaming the String
arg version to setStartDateAsStr, and then naming it explicitly in the
mapping file.
setStartDate(Date start) { ... }
setStartDateAsStr(String start) { ... }
this happened under JDO and XML too.
gerry
On Wednesday 20 February 2002 11:31 am, Todd V. Jonker wrote:
> 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
--
Brook's Law:
Adding manpower to a late software project makes it later.
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
