As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here: http://ws.stfx.eu/OAVG8IXKWOYA Don't need to filein the workaround of my previous email. Martin On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias@gmail.com> wrote:
Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code:
http://ws.stfx.eu/HYWM1ZB9R45K
(the first time I use the shared workspace :-)
if you file in the attached file, it materializes the new A class.
But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time
HTH Martin
On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@**public.gmane.org<roberto.minelli-BHDiRLqP7qo@public.gmane.org>wrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.