I'm using Rome 1.0 to parse an APExchange feed, which is in ATOM 1.0 format. Most of everything works well enough, but I've just noticed that my custom Module implementation is not working quite right, and I'm clsoe to positive that it has to do with my CopyFrom implementation in my ModuleImpl class.
What happens is that when Rome is invoked to parse a feed entry and pull namespace-specific information from that entry, the properties and attributes of the very last feed entry are applied to all parsed entries. So, if I have five feed entries coming to me, and I run through all of the entries, parse them, and use their module-specific properties to create content within my CMS, every generated piece of content shares the exact same properties, all of which come from entry #5, in this example.
Based on that behavior, and what I know of Rome, it definitely points to a CopyFrom/Cloning issue in my code. I've logged and debugged as best I can, but cannot spot what exactly I might be doing wrong.
This is my ModuleImpl class in its entirety. You can see that I am cloning using a deep copy methodology, which is necessary for Rome to do its thing, apparently. Does anyone know and understand exactly how Rome uses this class, and why it needs a CopyFrom method? What does it do with the clones of an existing and instantiated ModuleImpl class? Any ideas would be greatly appreciated, thanks all!
Joined: Nov 15, 2011
Found the issue.
In starred code above, you can see that I initialize my class' ApContentMetadata object just once, and in the constructor. So, since one copy of this class is used for parsing, the very last object parsed is the one whose values persist. Newbie bug, shucks. Oh, and for a solution, I moved initialization to the parse() method.