[XSTR-694] First Item in collection rendered ignoring the Annotations but others are correct

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Not A Bug
Affects Version/s: 1.4.2
Fix Version/s: None
Component/s: Converters
Labels:
None

JDK version and platform:
Sun 1.6.27

Description

I've created a Converter by extending the CollectionConverter. I overrided method as;

protected void writeItem(Object item, MarshallingContext context, HierarchicalStreamWriter writer) {
   writer.startNode("SlipItem");
   context.convertAnother(item);
   writer.endNode();
}

I registered it using registerConverter method and in the result; the first item rendered ignoring the Annotations (like XStreamAlias, XStreamOmitField), but the others are correct.

If it matters i create XStream object as;

XStream xs = new XStream();
xs.autodetectAnnotations(true);

Activity

Hide

Permalink

Jörg Schaible added a comment - 09/Mar/12 2:40 AM

This is more or less by design when you're working with auto-detected annotations. XStream cannot scan all classes upfront, therefore it used the AnnotationMapper as hook, when a converter looks for the name of a class or a field (Mapper.serializedClass or Mapper.serializedMember). This works normally quite well at serialization time and is unreliable at deserialization time (as documented). However, your converter does not make those calls to determine the name of the XML element, therefore are the annotations of the item's type not processed when the item is converted.

You have currently 3 possibilities:

don't use auto-detection
call mapper.serializedClass yourself (even if you ignore the result), before you call context.convertAnother
use @XStreamInclude on a top level type, it exists because of this problem

In future there might be a 4th possibility. Another user has developed a javac preprocessor that will collect the types at compile time and he promised to donate the code, but it has not yet happened.

BTW: Please consider to use the user's list as first level of contact, if you recognize a dubious symptom.

Show

Jörg Schaible added a comment - 09/Mar/12 2:40 AM This is more or less by design when you're working with auto-detected annotations. XStream cannot scan all classes upfront, therefore it used the AnnotationMapper as hook, when a converter looks for the name of a class or a field (Mapper.serializedClass or Mapper.serializedMember). This works normally quite well at serialization time and is unreliable at deserialization time ( as documented ). However, your converter does not make those calls to determine the name of the XML element, therefore are the annotations of the item's type not processed when the item is converted. You have currently 3 possibilities: don't use auto-detection call mapper.serializedClass yourself (even if you ignore the result), before you call context.convertAnother use @XStreamInclude on a top level type, it exists because of this problem In future there might be a 4th possibility. Another user has developed a javac preprocessor that will collect the types at compile time and he promised to donate the code, but it has not yet happened. BTW: Please consider to use the user's list as first level of contact, if you recognize a dubious symptom.

Hide

Permalink

Hakan Junior added a comment - 09/Mar/12 7:09 AM

Ok thanks. I've solved by 3rd option.

Show

Hakan Junior added a comment - 09/Mar/12 7:09 AM Ok thanks. I've solved by 3rd option.

Hide

Permalink

Jörg Schaible added a comment - 09/Mar/12 2:08 PM

Closing then.

Show

Jörg Schaible added a comment - 09/Mar/12 2:08 PM Closing then.

People

Assignee:

Jörg Schaible

Reporter:

Hakan Junior

Votes:

0 Vote for this issue

Watchers:

0 Start watching this issue

Dates

Created:

09/Mar/12 1:37 AM

Updated:

09/Mar/12 2:08 PM

Resolved:

09/Mar/12 2:08 PM