Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue while Parsing MxPacs00800103 (XML namespace without identifier in "any" field of Signature Envolope) #43

Open
graghsaka opened this issue Mar 7, 2022 · 3 comments

Comments

@graghsaka
Copy link

graghsaka commented Mar 7, 2022

I am facing issue while parsing AppHdr (BusinessAppHdrV01), specifically Sgntr (SignatureEnvelope).

In SignatureEnvelope there's a field "any" which is annotated by @XmlAnyElement.

My Xml string has a custom tag "XmlSgntr". So while parsing xml string, this "any" field is set as my custom tag. This is fine. But the problem is when my custom tag has XML namespace (xmlns), then it won't set. That is "any" field is set to null. This happens only when I set xmlns="https://acb/chjhj", but everything works fine when i set it as xmlns:xsi="https://acb/chjhj". i.e issue only exists when I set xml namespace without identifier (when xmlns value is URI).

What the reason behind this behaviour?

Edit:
So I debugged, and found another finding. This only happens if use xmlns="https://acb/chihj". If change it to xmln="https://acb/chih" or maybe anything else. That is I changed "xmlns" (namespace name). Seems like "xmlns" is causing the issue.

My Header:
<AppHdr xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:head.001.001.01 head.001.001.01.xsd" xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.01" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

My Signarure:
<XMLSgntrs xmlns="http://www.w3.org/2000/09/xmldsig#">

@zubri
Copy link
Member

zubri commented May 24, 2022

We probably need a type adapter to handle the Any elements. This is a long time pending issue.

As for the namespace, it is a bit strange, since the one that you said it works ant the other do not have significant differences.

@zubri
Copy link
Member

zubri commented May 25, 2022

This issue is similar to #39 and #41

Test case and a few exploration approaches have been pushed to:
#48

XmlAnyElement is expected to be parsed into a generic Element node.

The root cause is probably in our NamespaceAndElementFilter and MxReadImpl classes. But could not find a solution to fit al scenarios yet.

@graghsaka
Copy link
Author

pacs08.txt

@zubri thanks. I have also attached my xml request for reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants