Oliver Hutchison wrote:
>
> 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.
Awww come on now...you didn't have to argue that hard. I re-opened the
bug once I saw that it had been closed.
However the code appears to be JDO related, and I don't work on JDO
code. The JDO team are volunteers, so we'll need to be patient with
them. They are always looking for new volunteers to help out, so if
anyone wants to fix the bug, feel free to jump in and handle it,
otherwise please be patient with the current developers. If someone out
there is brave enough to do it, then please provide a test case with
your patch because the JDO guys are pretty busy.
Thanks,
--Keith
>
> 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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
