Affects Version/s: 1.3.2
Fix Version/s: None
Number of attachments :
Werner as discussed previously, I'll make an attempt at a patch for this when I have time.
Castor should be smart enough, when unmarshalling, to distinguish which Class to instantiate when more than one <map-to> element in a mapping for two or more Classes have the same "xml" attribute value. Essentially, the unmarshaller should infer teh class to set into: unmarshal.setClass(<most appropriate>.class)
See below for an instance of the problem:
I then unmarshal some XML that has the <ErLine> elements in them like so:
In the log I get this:
Ok, I think to myself, for some reason Castor can't work backwards from the <bind-xml> statement for the ErLine element to realize that <ErLine> really maps to ExpenseRequestFlexFacade (and the get/setExpenseRequestFacade) when unmarshalling... Also, the "object" being returned from unmarshal.unmarshal(..) ends up being is a Wallet, not a WalletFlexFacade!!!! So what I do is add "setErLine/getErLine" methods to WalletFlexFacade and change the <field> name attribute in the mapping from "expenseRequests" to "erLines" in hopes that Castor will notice that WalletFlexFacade is the right class to instantiate, not Wallet. Nope, that didn't work. It's just hell bent on using "Wallet" because I think it's just the first mapping it found with the proper <map-to> element.
Instead what should happen is when Castor finds two mappings with the same <map-to> xml attribute, it should inventory the differences between the two mappings and determine which mapping is more appropriate for the XML being unmarshalled (i.e. if the XML has a <ErLines> element, and the WalletFlexFacade has a mapping for that but the Wallet doesn't, it should choose the WalletFlexFacade)