Werner Guttmann wrote:
On Tue, 11 May 2004 10:39:09 -0600 (MDT), Bruce Snyder wrote:
This one time, at band camp, Jon Wilmoth said:
JW>I agree it is a pretty complex object, but it allows JW>for nice reuse of existing objects to form a new JW>assignment relationship. While I look for a way to JW>simplify, I think I've found a bug or undocumented JW>feature ;) JW> JW>I posted a message a couple of days ago about a JW>getting an JW>org.exolab.castor.jdo.DataObjectAccessException: Type JW>conversion error: could not set value of FieldMolder JW>of JW>com.apex.chronos.app.authorization.OrganizationRoleAssignment.setorganization(com.apex.chronos.app.party.Organization JW>organization) with value of type java.lang.Long JW> JW>I thought the issue had resolved itself and was merely JW>a problem with my browser caching my error page. JW>Unfortunately, the same error popped up a couple of JW>builds later. After spending a couple of days trying JW>to hunt down my mapping error (including creating JW>another, pure relationship mapping of Author, Book, JW>and Publisher in a BookContract), I noticed that I was JW>getting the same type of error but with the JW>setPublisher method on the BookContract. Commenting JW>out the Publisher object on the BookContract fixed the JW>problem...the Author and Book objects came back just JW>fine when doing a query on BookContract. Comparing JW>the mappings, the Author, Book And Publisher field JW>definitions were all the same (with different column JW>names obviously), so I thought I was back at the same JW>dead end. Then I realized that the Publisher JW>"mapping" element in the database xml came after the JW>BookContract "mapping" element, while the Author and JW>Book (both of which worked) were positioned before the JW>BookContract mapping element. The same situation JW>existed with my original mapping of JW>OrganizationRoleAssignment (Person and Role were JW>positioned below, while Organization was positioned JW>above). I moved the BookContract and JW>OrganizationRoleAssignment mapping element in the JW>database xml doc to the bottom and the "Type JW>conversion error: could not set value of FieldMolder" JW>problem went away. I'm just happy I've seemingly JW>fixed a problem that's stalled me for 4 days and can JW>make sure I position mapping documents correctly in JW>the database file, but is this the way it should work? JW> JW>BROKEN: JW><database> JW> <mapping href="CASTOR-MAPPING-Author.xml"/> JW> <mapping href="CASTOR-MAPPING-Book.xml"/> JW> <mapping href="CASTOR-MAPPING-BookContract.xml"/> JW> <mapping href="CASTOR-MAPPING-Publisher.xml"/> JW></database> JW> JW>FIXED: JW><database> JW> <mapping href="CASTOR-MAPPING-Author.xml"/> JW> <mapping href="CASTOR-MAPPING-Book.xml"/> JW> <mapping href="CASTOR-MAPPING-Publisher.xml"/> JW> <!-- Must be below reference objects to resolve JW>setXXX --> JW> <mapping href="CASTOR-MAPPING-BookContract.xml"/> JW></database>
Another solution to this ...
Bruce, just out of curiosity, would you consider this to be a bug or not ? As you are able to provide a workaround, it might as well be that there's already a bug report out there I cannot find.
AFAIK, there has been no bug filed for this. It has always been an issue with the order in which mapping descriptors are unmarshalled but I'm not sure exactly where the problem lies. At one time I debugged it a bit, but I never came to any conclusions as other issues took a higher priority.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://incubator.apache.org/projects/geronimo.html
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
