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 is to only use a single <mapping> element
for the top level object. Then inside of that top level object's
mapping descriptor, simply use <include> elements to include the
other mapping descriptors like so:
<mapping>
<include href="path/to/mapping1.xml" />
<include href="path/to/mapping2.xml" />
<class name="foo.bar.baz.TopLevelObject">
...
</class
</mapping>
HTH.
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
