Ok, I'm sure *half* of the patch is correct. Basically, I've got a problem with add methods not getting discovered properly - reporting that it can't find a method to use, even though it seems to plainly have one. :)

Here's the patch:

[EMAIL PROTECTED]:~/Source/castor/src $ cvs diff main/org/exolab/castor/persist/FieldMolder.java
Index: main/org/exolab/castor/persist/FieldMolder.java
===================================================================
RCS file: /cvs/castor/castor/src/main/org/exolab/castor/persist/ FieldMolder.java,v
retrieving revision 1.4
diff -r1.4 FieldMolder.java
591c591
< = findAccessor( javaClass, "add" + capitalize( name ), null, false );
---
> = findAccessor( javaClass, "add" + capitalize( name ), declaredClass, false );
640c640
< if ( _defaultReflectService._setMethod == null && !fieldMap.getLazy() )
---
> if ( _defaultReflectService._setMethod == null && !fieldMap.getLazy() ) {
641a642,643
> if (_defaultReflectService._addMethod!=null) _addable = true;
> }

The second part's easy; _addable never got set to true, even though we went looking for an _addMethod to use.

The first one's not so clear cut; I just had this gut instinct that null isn't what we're looking for, and others around it were using declaredClass. I *believe* that's a good guess - one of you guys who actually understands this area of the code should tell me if I've done badly. :)

It's odd, because I don't seem to encounter it all the time, but by all rights, I should, whenever both get-method="getter" and set-method="adder" appear. (also, shouldn't this be split out so that get-, set-, and create- operate independently from one another, rather than only checking get-method/set-method when both are set to true?


Attachment: smime.p7s
Description: S/MIME cryptographic signature

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to