FasterXML / jackson-dataformat-xml

Extension for Jackson JSON processor that adds support for serializing POJOs as XML (and deserializing from XML) as an alternative to JSON
Apache License 2.0
561 stars 221 forks source link

Conflicting Getter Definitions for Different List Properties with Same Element as Content (dup of #27) #656

Closed evoelise closed 4 weeks ago

evoelise commented 1 month ago

Apologies for the severe redaction in code examples & reported errors.

I am getting the following exception with Jackson v2.13.4:

org.springframework.http.converter.HttpMessageConversionException: Type definition error: [simple type, class com.xxxx.Message];
nested exception is com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Conflicting getter definitions for property "Client": com.xxxx.Message#getSentByClients()
vs com.xxxx.Message#getReceivedByClients() (through reference chain: java.util.ArrayList[0])
            at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.writeInternal(AbstractJackson2HttpMessageConverter.java:462)
            at org.springframework.http.converter.AbstractGenericHttpMessageConverter.write(AbstractGenericHttpMessageConverter.java:104)

It should be possible to have XML that contains different named list elements that contain the same named list items, for example:

<Message>

  <sent_by_clients>
    <client>client_1</client>
    <client>client_2</client>
    <client>client_3</client>
  </sent_by_clients>

  <received_by_clients>
    <client>client_4</client>
    <client>client_5</client>
    <client>client_6</client>
  </received_by_clients>

</Message>

To this end I have set up something similar to the following Java code:

@XmlRootElement(name="Message")
@JsonInclude(Include.NON_NULL)
public class Message {

            private List<Client> sentByClients;
            private List<Client> receivedByClients;

            @JacksonXmlElementWrapper(localName = "sent_by_clients")      
            @JacksonXmlProperty(localName = "client")    
            @JsonProperty("sent_by_clients")
            public List<Client> getSentByClients() {
                        return sentByClients;
            }

            public void setSentByClients(List<WebClient> aSentByClients) {
                        sentByClients = aSentByClients;
            }

            @JacksonXmlElementWrapper(localName = "received_by_clients")
            @JacksonXmlProperty(localName = "client")    
            @JsonProperty("received_by_clients")
            public List<Client> getReceivedByClients() {
                        return receivedByClients;
            }

            public void setReceivedByClients(List<WebClient> aReceivedByClients) {
                        receivedByClients = aReceivedByClients;
            }
}

I believe this should work - but if we do this we get an error stating the there are conflicting getter definitions even though the getters are for different list properties. Should the libraries realise that even though the same named JacksonXmlProperty are used these are part of different elements due to the different named JacksonXmlElementWrappers?

Am I correct that this should work and this is an issue - or am I missing something and I should code or annotate this in a different way?

cowtowncoder commented 4 weeks ago

Wrong repo, will move.

cowtowncoder commented 4 weeks ago

This should work, but unfortunately due to implementation details, "inner" element name is used as a key leading to the problem. So while wrapper names differ, they are not used for fetching property information. I think there is probably an issue here already... I think #27 is same as this one.

I am not sure there is a work-around available, unfortunately.

evoelise commented 4 weeks ago

@cowtowncoder Thanks for moving to the correct repo & your answer. Also I can confirm it looks like the same issue as #27. I did search for the issue but didn't find it when I looked. It's not encouraging that #27 has been open since 2012 but I am happy for this to be closed as a duplicate.

cowtowncoder commented 4 weeks ago

Yes, it is unfortunate one and there is no work on-going to resolve it (PRs welcome as usual, but aside). Closing as dup of #27.