Thanks Jörg!
Let me just ask you one last question concerning a behavior from which I'm not
sure if it is correct:
Given the following converter and a class using it for one of its properties:
public class MyConverter implements Converter {
public MyConverter(Class<?> clazz) {
....
}
....
}
class MyObject {
@XStreamConverter(value=MyConverter.class, types=AnotherClass.class)
private MyClass prop;
}
=> My converter gets instantiated with "MyClass.class" as constructor argument!
I would have thought that "AnotherClass.class" would be used since it is
specified in the annotation.
Is this expected behavior? Has the current type always priority?
Playing around a little but, I found out that, if I specify another constructor
in my converter, taking two class instances,
then the second argument will be "AnotherClass.class".
Just not sure what are the exact rules for argument matching in converter
constructors..
Thanks for throwing some light on this, Jörg!
> [email protected] wrote:
>
> > Thanks for information, Jörg.
> >
> > So if I understood you correctly, local converters which are declared via
> > annotation are not cached ?
>
> You can only have one per field. If you register two, the second wins. The
> converter instance is part of the XStream instance.
>
> > As you pointed out, I successfully tested that if a converter has a
> > constructor which takes, among other arguments, the class that should be
> > converted, then XStream adds this class argument when instantiating the
> > converter. This is very convenient and saves me from specifying the class
> > in the @XStreamConverter annotation. Can I rely on this feature in future
> > releases?
>
> Yes. It is covered by unit tests, see
> com/thoughtworks/acceptance/annotations/ParametrizedConverterTest.java.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
