Smalltalk › Pharo › Pharo Smalltalk Developers

Collect all references to AnObsoleteFoo

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

roberto.minelli@usi.ch

Collect all references to AnObsoleteFoo

Hi,

I'm getting crazy about obsolete behaviors and any help here is really appreciated.

In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).

Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.

Now my question is, apart from executing this small piece of code...

SmalltalkImage current fixObsoleteReferences.
SystemNavigation new obsoleteBehaviors size > 0
ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]

…in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?

For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated.
More important, I also don't know how to eliminate them.

Thanks in advance,
Roberto

Max Leske

Re: Collect all references to AnObsoleteFoo

I've had the same problem just recently but am stuck in a bit of work right now. I hope to elaborate at length tomorrow.

Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them. To fix obsolete classes you need to remove all references to it, be it in a dictionary or in a compiled method where you used the class name.
Can you post the list of classes that are obsolete?

Cheers,
Max

On 01.04.2013, at 16:51, [hidden email] wrote:

> Hi,
>
> I'm getting crazy about obsolete behaviors and any help here is really appreciated.
>
> In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).
>
> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.
>
> Now my question is, apart from executing this small piece of code...
>
> SmalltalkImage current fixObsoleteReferences.
> SystemNavigation new obsoleteBehaviors size > 0
> ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
>
> …in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?
>
> For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated.
> More important, I also don't know how to eliminate them.
>
> Thanks in advance,
> Roberto
>
>

Fernando olivero-2

Re: Collect all references to AnObsoleteFoo

In reply to this post by roberto.minelli@usi.ch

Ciao Roberto,

Whenever you remove a class that is still referenced in the system, an
ObsoleteClass takes the place of the removed class. In the late-bound
spirit of Smalltalk, the system allows removing the classes and
dealing with the current references later.

If i may question the source of your problem: "a Dictionary
(containing receivers of method calls, i.e., classes) that I need to
serialize in a file (i.e., using Fuel)", are you sure you need to
serialize the actual classes? or just the names? or even a description
of the class within Ring? Think about what you are modeling with a
Dictionary that holds <messages,set of receivers>, and maybe try to
reify that concept.

Fernando

On Mon, Apr 1, 2013 at 9:58 PM, Max Leske <[hidden email]> wrote:

> I've had the same problem just recently but am stuck in a bit of work right now. I hope to elaborate at length tomorrow.
>
> Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them. To fix obsolete classes you need to remove all references to it, be it in a dictionary or in a compiled method where you used the class name.
> Can you post the list of classes that are obsolete?
>
> Cheers,
> Max
>
>
>
> On 01.04.2013, at 16:51, [hidden email] wrote:
>
>> Hi,
>>
>> I'm getting crazy about obsolete behaviors and any help here is really appreciated.
>>
>> In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).
>>
>> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.
>>
>> Now my question is, apart from executing this small piece of code...
>>
>> SmalltalkImage current fixObsoleteReferences.
>> SystemNavigation new obsoleteBehaviors size > 0
>> ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
>>
>> …in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?
>>
>> For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated.
>> More important, I also don't know how to eliminate them.
>>
>> Thanks in advance,
>> Roberto
>>
>>
>
>

Yanni Chiu

Re: Collect all references to AnObsoleteFoo

In reply to this post by roberto.minelli@usi.ch

On 01/04/13 10:51 AM, [hidden email] wrote:
>
> For me the entire "behavior" of obsolete classes is obscure and I
> don't know how those classes are originated.

They arise when you delete a class, but you still have references to the
class in the image. You could have instances of the deleted class,
references to the class in a method, or even subclasses that refer the
the deleted class.

> More important, I also don't know how to eliminate them.

Make sure there are no dangling references, before you delete the class.

Another possibility depends on whether the "obsolete" class has a
non-obsolete equivalent if the image where you're de-materializing the
Fuel file. If there is no equivalent class, but you still want to
materialize the Fuel file there, you can set up a mapping to map the
object to some other class (e.g. ClassThatWasDeleted class or even just
used Object class). The object will be materialized, but probably most
of it's instance variable values will be thrown away. This may or may
not be the behaviour you want though.

roberto.minelli@usi.ch

Re: Collect all references to AnObsoleteFoo

In reply to this post by Max Leske

On Apr 1, 2013, at 9:58 PM, Max Leske <[hidden email]> wrote:

> Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them.

I already tried. But then I had problems in materialization so I aborted the trial ;)

> Can you post the list of classes that are obsolete?

Obsolete classes I encountered were all "obsolete versions" of classes I defined :)

>
> Cheers,
> Max
>
>
>
> On 01.04.2013, at 16:51, [hidden email] wrote:
>
>> Hi,
>>
>> I'm getting crazy about obsolete behaviors and any help here is really appreciated.
>>
>> In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).
>>
>> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.
>>
>> Now my question is, apart from executing this small piece of code...
>>
>> SmalltalkImage current fixObsoleteReferences.
>> SystemNavigation new obsoleteBehaviors size > 0
>> ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
>>
>> …in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?
>>
>> For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated.
>> More important, I also don't know how to eliminate them.
>>
>> Thanks in advance,
>> Roberto
>>
>>
>
>

roberto.minelli@usi.ch

Re: Collect all references to AnObsoleteFoo

In reply to this post by Fernando olivero-2

Thanks Fernando,

On Apr 1, 2013, at 11:51 PM, Fernando Olivero <[hidden email]> wrote:

> Ciao Roberto,
>
> Whenever you remove a class that is still referenced in the system, an
> ObsoleteClass takes the place of the removed class. In the late-bound
> spirit of Smalltalk, the system allows removing the classes and
> dealing with the current references later.

I see. I'm not sure I agree with this philosophy, but I see the point.

> If i may question the source of your problem: "a Dictionary
> (containing receivers of method calls, i.e., classes) that I need to
> serialize in a file (i.e., using Fuel)", are you sure you need to
> serialize the actual classes? or just the names? or even a description
> of the class within Ring? Think about what you are modeling with a
> Dictionary that holds <messages,set of receivers>, and maybe try to
> reify that concept.

I totally agree with you Fernando. That was just a quick and dirty prototype ;)

> Fernando
>
>
>
>
> On Mon, Apr 1, 2013 at 9:58 PM, Max Leske <[hidden email]> wrote:
>> I've had the same problem just recently but am stuck in a bit of work right now. I hope to elaborate at length tomorrow.
>>
>> Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them. To fix obsolete classes you need to remove all references to it, be it in a dictionary or in a compiled method where you used the class name.
>> Can you post the list of classes that are obsolete?
>>
>> Cheers,
>> Max
>>
>>
>>
>> On 01.04.2013, at 16:51, [hidden email] wrote:
>>
>>> Hi,
>>>
>>> I'm getting crazy about obsolete behaviors and any help here is really appreciated.
>>>
>>> In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).
>>>
>>> Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.
>>>
>>> Now my question is, apart from executing this small piece of code...
>>>
>>> SmalltalkImage current fixObsoleteReferences.
>>> SystemNavigation new obsoleteBehaviors size > 0
>>> ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
>>>
>>> …in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?
>>>
>>> For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated.
>>> More important, I also don't know how to eliminate them.
>>>
>>> Thanks in advance,
>>> Roberto
>>>
>>>
>>
>>
>

roberto.minelli@usi.ch

Re: Collect all references to AnObsoleteFoo

In reply to this post by Yanni Chiu

Thanks for your answer!

On Apr 2, 2013, at 12:03 AM, Yanni Chiu <[hidden email]> wrote:

> They arise when you delete a class, but you still have references to the class in the image. You could have instances of the deleted class, references to the class in a method, or even subclasses that refer the the deleted class.

Is there any way to "browse" through such references to understand where are they?

Yanni Chiu

Re: Collect all references to AnObsoleteFoo

On 02/04/13 12:50 AM, [hidden email] 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.

tinchodias

Re: Collect all references to AnObsoleteFoo

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 <[hidden email]> wrote:

On 02/04/13 12:50 AM, [hidden email] 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.

FLDecoder-globalClassNamed.st (730 bytes) Download Attachment

tinchodias

Re: Collect all references to AnObsoleteFoo

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 <[hidden email]> 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 <[hidden email]> wrote:

On 02/04/13 12:50 AM, [hidden email] 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.

roberto.minelli@usi.ch

Re: Collect all references to AnObsoleteFoo

Martin, your solution is awesome.

I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.

Thanks a lot,
R

On Apr 5, 2013, at 4:59 PM, Martin Dias <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> wrote:
> On 02/04/13 12:50 AM, [hidden email] 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.
>
>
>
>

Mariano Martinez Peck

Re: Collect all references to AnObsoleteFoo

Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)?

If not, could be write your awesome code in the Fuel website?

Thanks!!! :)

On Sat, Apr 6, 2013 at 8:26 AM, [hidden email] <[hidden email]> wrote:

Martin, your solution is awesome.

I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.

Thanks a lot,
R

On Apr 5, 2013, at 4:59 PM, Martin Dias <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]> wrote:
> On 02/04/13 12:50 AM, [hidden email] 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.
>
>
>
>

--
Mariano
http://marianopeck.wordpress.com

roberto.minelli@usi.ch

Re: Collect all references to AnObsoleteFoo

I'd say that handling obsolete reference this way is very good! I'd put this behavior in Fuel!

Cheers,
R

On Apr 6, 2013, at 2:27 PM, Mariano Martinez Peck <[hidden email]> wrote:

> Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)?
> If not, could be write your awesome code in the Fuel website?
>
> Thanks!!! :)
>
>
>
>
> On Sat, Apr 6, 2013 at 8:26 AM, [hidden email] <[hidden email]> wrote:
> Martin, your solution is awesome.
>
> I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.
>
> Thanks a lot,
> R
>
> On Apr 5, 2013, at 4:59 PM, Martin Dias <[hidden email]> wrote:
>
> > 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 <[hidden email]> 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 <[hidden email]> wrote:
> > On 02/04/13 12:50 AM, [hidden email] 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.
> >
> >
> >
> >
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com

tinchodias

Re: Collect all references to AnObsoleteFoo

pffff thank you. The word 'awesome' is too much, but well, I can put the snippet somewhere in the doc.

I don't know if this should be the default behaviour in Fuel, since it will add the dependency to Ring.

Also we can discuss about removing the "defensive" error during serialization: as you could see, technically there is no problem to serialize the obsolete class. We decided to raise an error just because as users we found that almost always when you are serializing the obsolete, it was due to some mistake, and you discover that the obsolete was in the .fuel file later when you materialize.

Alternatively, we could just raise a "class not found" error during materialization.

cheers,

Martin

ps: I'd like to see the video of Max's presentation in PharoConf!

On Sun, Apr 7, 2013 at 2:47 PM, [hidden email] <[hidden email]> wrote:

I'd say that handling obsolete reference this way is very good! I'd put this behavior in Fuel!

Cheers,
R

On Apr 6, 2013, at 2:27 PM, Mariano Martinez Peck <[hidden email]> wrote:

> Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)?
> If not, could be write your awesome code in the Fuel website?
>
> Thanks!!! :)
>
>
>
>
> On Sat, Apr 6, 2013 at 8:26 AM, [hidden email] <[hidden email]> wrote:
> Martin, your solution is awesome.
>
> I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.
>
> Thanks a lot,
> R
>
> On Apr 5, 2013, at 4:59 PM, Martin Dias <[hidden email]> wrote:
>
> > 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 <[hidden email]> 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 <[hidden email]> wrote:
> > On 02/04/13 12:50 AM, [hidden email] 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.
> >
> >
> >
> >
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com