Patrick Lioi wrote:
>
> 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.
The mapping file will use "Block.class" because that's how you specified
it. Though I am surprised that you didn't get errors, because it uses
reflection to make sure that the type defined in your java class matches
the type defined in the mapping file. However maybe because your field
is a collection that it wasn't able to do this check.
I am now going to assume you never had a class mapping for Block? Such
as:
<class name="Block"/>
...
</class>
If this is true then that explains why the unmarshalling may have found
the correct class. Since it didn't find a ClassDescriptor for "Block" in
the mapping file, it automatically tries to use the package name of the
parent class. In this case "LiveSyncd". It prepends this name to
"Block", to get "LiceSyncd.Block". Since it found that class, it will
use introspection to automatically create the appropriate
ClassDescriptor.
I am just guessing here, but I think that's probably what may have
happend. Since your java class was really using the LiveSyncd.Block and
that's the one Castor used, then it didn't have any runtime errors when
Castor tried to add an instace of LiveSyncd.Block to LiveSyncd.Docstate.
Again...I am just speculating here because I don't have a copy of your
code and I didn't examine what was happening at runtime.
>
> 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.
Yes...because that's how you specified it in the mapping file:
"Block"...
> But when my program unmarshalled/marshalled an instance
> of Block, the correct/packaged version was actually instantiated.
>
see my above speculation...
> 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.
Yes...the mapping file definately needs it because the mapping file
doesn't do any "package" guessing like the marshalling framework will
do.
>
> Changing the mapping "type" attribute to "LiveSyncd.Block" and removing
> the older Block.class file fixed the problem.
Yes, the mapping file needs to be explicit.
>
> Should the mapping loader and marshalling mechanism be able to recognize
> inconsistencies in the fully-qualified class names?
>
Probably, but the marshalling framework tries to be smart. The mapping
file doesn't have much "smart" logic to it. Not to mention, you used a
collection, which might be why Castor was unable to recognize the
inconsistencies.
Try adding:
<class name="Block">
...
</class>
And see if you get errors during marshalling/unmarshalling. You'll have
to put back the old Block.class back for the mapping file to properly
get loaded.
--Keith
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
