XStream

Collections without enclosing list element

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.6
  • Fix Version/s: 1.0.2
  • Component/s: Converters
  • Labels:
    None

Description

Would like to use XStream for all ejb-jar.xml, web.xml, ra.xml, and application.xml marshalling/unmarshalling in Geronimo/OpenEJB. Sadly, changing the xml format would involve assasination of several people in the spec committies and bankruptsy of several major tech companies ... or a stylesheet.

Attached is a test case for a dtd that may look like this:
<!ELEMENT person (name,age,phoneNumber+)>
<!ELEMENT phoneNumber (#PCDATA)>

This is used pretty much everywhere in all of the J2EE-related dtds.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Blevins added a comment -

Attached is a test case and maven report of the test failing

Show
David Blevins added a comment - Attached is a test case and maven report of the test failing
Hide
Permalink
Joe Walnes added a comment -

A few people have asked for it now, so I'll add support for this. It will be post 1.0 though.

Show
Joe Walnes added a comment - A few people have asked for it now, so I'll add support for this. It will be post 1.0 though.
Hide
Permalink
David Blevins added a comment -

Looking at the problem a little further, it seems one technique would be to let the ReflectionConverter trump the Collection or Array Converters when there is an explicit mapping for the element in the ClassMapper, then let the ReclectionProvider figure out how to resolve the type conflict in the writeField method.

You could then have a table of Mutator (aka, Setter) classes that know how to deal with the field type (list, array, plain object). You could also have a canMutate method on the Mutator and use a list like you do with the Converter list.

The trick is obviously on marshalling, where you'd need to do the complete opposite for balance.

Show
David Blevins added a comment - Looking at the problem a little further, it seems one technique would be to let the ReflectionConverter trump the Collection or Array Converters when there is an explicit mapping for the element in the ClassMapper, then let the ReclectionProvider figure out how to resolve the type conflict in the writeField method. You could then have a table of Mutator (aka, Setter) classes that know how to deal with the field type (list, array, plain object). You could also have a canMutate method on the Mutator and use a list like you do with the Converter list. The trick is obviously on marshalling, where you'd need to do the complete opposite for balance.

People

  • Assignee:
    Unassigned
    Reporter:
    David Blevins
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: