It is possible for a Castor mapping file refering to a class to be
loaded without error, and for a subsequent unmarshalling of a
*different* class with the same name (in a different package) using that
mapping file. In other words, the wrong .class file is used to load the
mapping file, while the correct .class file is used to marshal, all
without any warnings/error messages.
Example:
I first developed a class named Block and neglected to put the package
name at the top of the source file. After making a build and later
adding the package name and rebuilding, two instances of Block.class
existed. One was in the proper package and had some bug fixes, while
the other wasn't in any package and had accidentally not been cleaned
away in the build process. My mapping file at this point contained
these lines:
<class name="LiveSyncd.Docstate">
<field name="blocks"
type="Block" collection="collection" />
</class>
When my program loaded this mapping file, Castor used the non-packaged
version of the class file to determine that it had the proper get/set
functions etc. But when my program unmarshalled/marshalled an instance
of Block, the correct/packaged version was actually instantiated.
In other words, the executable relied on the existence of the
older/buggy class file, but all my bug fixes were working. The compiled
program would only execute when the non-packaged .class file was also in
the classpath, even though it was only used to validate the mapping
file.
Changing the mapping "type" attribute to "LiveSyncd.Block" and removing
the older Block.class file fixed the problem.
Should the mapping loader and marshalling mechanism be able to recognize
inconsistencies in the fully-qualified class names?
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
