Problems with namespaces in xml files from third party

[StefanMMS]

Hi. I just switched from version 0.86.2 -> 0.86.3

now I am facing the problem that I need to define empty namespaces in my data class.
This is the XML I need to parse:

<ns0:salesLimit xmlns:ns0="http://someNamespace">
    <quantitySalesLimit xmlns="">-3</quantitySalesLimit>
    <productID xmlns="">3948572</productID>
    <outletId xmlns="">2758234</outletId>
    <distributionChannel xmlns="">MM</distributionChannel>
    <subsidiary xmlns="">AT</subsidiary>
</ns0:salesLimit>

This is my Dataclass:

@Serializable
@XmlSerialName("salesLimit")
data class SaldoSalesLimitDto(
    @XmlElement
    val quantitySalesLimit: Int,
    @XmlElement
    val productID: String,
    @XmlElement
    val outletId: String,
    @XmlElement
    @XmlSerialName("distributionChannel")
    val distributionChannel: SalesLine,
    @XmlElement
    @XmlSerialName("subsidiary")
    val subsidiary: Country,
)

With version 0.86.2 this worked fine.
With the version 0.86.3 I get following Exception:

 nl.adaptivity.xmlutil.XmlException: Local name "{http://someNamespace}salesLimit" for root tag does not match expected name "salesLimit"

If I add the namespace to my data class I get following Exception:

 nl.adaptivity.xmlutil.serialization.UnknownXmlFieldException: Could not find a field for name (....saleslimits.dto.SaldoSalesLimitDto) {http://someNamespace}salesLimit/quantitySalesLimit (Element)
  candidates: {http://someNamespace}quantitySalesLimit (Element), {http://someNamespace}productID (Element), {http://someNamespace}outletId (Element), {http://someNamespace}distributionChannel (Element), {http://someNamespace}subsidiary (Element) at position Line number = 2

Could somebody tell me what changed in the new version and if there is a way to ignore namespaces during deserialization?
Thanks very much

[pdvrieze]

The issue is with the way that namespace inheritance works. In other words, it tries to make a guess, and there was a problem with the guessing. Also, for the root element only, it will use whatever name the element actually has in the document rather than the one declared on the type.
Another factor to consider is that the default parameter values for @XmlSerialName are interpreted as automatic prefix/namespace rather than empty. Given your data your DTO is actually incorrect in that you need to set the namespace (and thus XmlSerialName on all members). The current DTO rather relies on compatibility logic (it has no namespace, but is parsed as if it has a namespace - it should have a namespace) - note that the DTO would also not serialize correctly if not given an explicit tag name on serialization.

The following DTO should work (And yes, this is a poorly designed format):

@Serializable
@XmlSerialName("salesLimit", "http://someNamespace", "ns1")
data class SaldoSalesLimitDto(
    @XmlElement
    @XmlSerialName("quantitySalesLimit", "", "")
    val quantitySalesLimit: Int,
    @XmlElement
    @XmlSerialName("productId", "", "")
    val productID: String,
    @XmlElement
    @XmlSerialName("outletId", "", "")
    val outletId: String,
    @XmlElement
    @XmlSerialName("distributionChannel", "", "")
    val distributionChannel: SalesLine,
    @XmlElement
    @XmlSerialName("subsidiary", "", "")
    val subsidiary: Country,
)

[StefanMMS]

Thanks Paul for the quick answer even I am not satisfied with that solution .. I hoped I missed some configurations. Unfortunately not ... so I will update my DTO.

[pdvrieze]

The thing is that the system assumes that child tags have the same namespace as their owners. Somehow the xml file you have instead adds items in the default namespace as children of the outer tag. If you look for example xmlschema this is not how namespaces are intended to be used (a schema file can only define a single namespace's elements, but can import from other namespaces).

While the document you're dealing with is poorly designed at least it is actually valid xml (there are many examples of "almostXml" where the users didn't quite understand how XML is supposed to work).

As an alternative, the name is ultimately determined in the policy (through effectiveName). You can extend the default policy to have a different naming policy. (The algorithm in 0.86.2 ignored that policy for the root tag and was as such inconsistent).