Calling context.convertAnother vs directly calling marshal/unmarshal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Calling context.convertAnother vs directly calling marshal/unmarshal

Gabriel Rossetti

Hi all,

I have custom converters which call other converters, currently I call context.convertAnother() but this takes time since it cycles through the converters and calls canConvert() (even though I gave it the converter instance). Anyways, what is the advantage to use this method vs directly calling the marshal/unmarshal on the converter instance? I don't really see the advantage in this case since I know which converter to use, am I missing something?

Thanks,
Gabriel

Reply | Threaded
Open this post in threaded view
|

Re: Calling context.convertAnother vs directly calling marshal/unmarshal

Jörg Schaible-4
Hi Gabriel,

Gabriel Rossetti wrote:

> Hi all,
>
> I have custom converters which call other converters, currently I call
> context.convertAnother() but this takes time since it cycles through the
> converters and calls canConvert()

Only once, the selection is cached.

> (even though I gave it the converter
> instance).

Normally you don't provide an own converter, but if you do, XStream checks
its usability.

> Anyways, what is the advantage to use this method vs directly
> calling the marshal/unmarshal on the converter instance? I don't really
> see the advantage in this case since I know which converter to use, am I
> missing something?

References to/from such elements will not work. No detection of endless
recursion in case of a cycle in an object graph. No reuse of existing
converter instance for elements of same type elsewhere (some converter
implementations build up own caches).

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email