Todd, I have also found this problem and have raised it as a bug with the castor developers, see: http://bugzilla.exolab.org/show_bug.cgi?id=834
I had to argue hard to get this accepted as a bug, but there's been no movement with regards to a fix and I haven't had the time to produce one myself. The only way to get things to work is to change your getShifts method to return and ArrayList instead of a List (not on option I'd be happy with). Or you can patch castor so its not so strict about types (this is what i did). You want to look at the FieldMolder.findAccessor method. Sorry I cant provide a patch I'm totally flat out at the moment (launch day tomorrow). Oliver Hutchison -----Original Message----- From: Todd V. Jonker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 13 February 2002 12:18 PM To: [EMAIL PROTECTED] Subject: [castor-dev] 0.9.3.9 collection incompatibility Hello, I'm attempting to migrate from Castor 0.9.3 to 0.9.3.9 and have discovered some strange problems. I'm using Castor JDO on top of PostreSQL. My problem is that a mapping file that worked fine now fails to work properly with regards to the collections used for many-to-many mappings. I get this error: [junit] org.exolab.castor.mapping.MappingException: The return type for method public java.util.List inpath.mdpath.ScheduleTemplate.getShifts() does not match the declared field type java.util.Collection Here's the relevant mapping snippet: -------- mapping.xml -------- <class name="inpath.mdpath.ScheduleTemplate" identity="id" key-generator="MAX"> <map-to table="schedule_template" /> <field name="id" type="integer" > <sql name="id" type="integer"/> </field> <field name="shifts" type="inpath.mdpath.castor.CastorShift" required="true" collection="collection"> <sql many-table="schedule_template_shift" many-key="template_id" name="shift_id" /> </field> <field name="period" type="integer"> <sql name="minutes_per_row" type="integer" /> </field> </class> -------- And the related code: -------- ScheduleTemplate.java -------- public class ScheduleTemplate extends Timeline { public List getShifts() { ... Return an (unmodifiable) ArrayList ... } public void setShifts(List shifts) { ... Copy values from shifts into internal ArrayList ... } public void addShift(Shift shift) { ... Add shift to my internal ArrayList ... } public void removeShift(Shift shift) { ... You can guess ... } } -------- My first question is: why does this fail where it worked fine before? I have quite a bit of code that uses the idiom of get/set via List. In trying to find a solution, I saw the following snippet in the ChangeLog: -------- XML & JDO: Now the return type of get-method must be a super-class of or equal to the class declared in mapping.xml (was: sub-class). Note, that now "arraylist" can be used as a value of "collection" attribute in mapping.xml -------- Can someone in-the-know please explain what in blazes this means? It sounds like a direct violation of the covariance principle. Seeing the note about arraylist, I modified the mapping accordingly (since ArrayList is what I'm actually using anyway). Now I get a different error: -------- [junit] org.exolab.castor.mapping.MappingException: The method set/addShifts in class inpath.mdpath.ScheduleTemplate accepting/returning object of type class inpath.mdpath.castor.CastorShift was not found -------- Another WTF moment. I've seen this horrible, incomprehensible error message before, and now it just makes no sense whatsoever. I've tried to find documentation on how to do this, but as far as I can tell, the 1-N and N-M mapping design is almost entirely neglected except for the very simplistic example code. For example, when is a single-element addFoo(Foo) method used instead of the setFoos(List) ? I've seen both called at different times, and I can't figure out what the rules are. If anybody can explain exactly how this is supposed to work, what the types should be, in the various places, I'd greatly appreciate it. I'm having a show-stopping inexplicable problem with 0.9.3 and I'd like to migrate to the newer code in hopes that it goes away! Thanks, .T. 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
