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

Fix namespace prefix handling with StreamingPayload #33

Closed
wants to merge 1 commit into from

Conversation

veithen
Copy link
Contributor

@veithen veithen commented May 27, 2015

The getName() method in JaxbStreamingPayload doesn't report the actual
namespace prefix that is later generated by the writeTo method. With
Axiom 1.2.13 that didn't cause problems, but 1.2.14 is less lenient,
causing an error as described in AXIOM-463.

This change:

  • Updates the StreamingPayload documentation to specify that the
    namespace prefix in the QName returned by getName() has no significance
    (which is effectively how things are currently).
  • Updates AxiomSoapBody so that it Axiom is aware that the namespace
    prefix of the created OMSourcedElement is unknown.
  • Modifies the unit test for setStreamingPayload so that it uses a
    StreamingPayload with a prefix mismatch.

The getName() method in JaxbStreamingPayload doesn't report the actual
namespace prefix that is later generated by the writeTo method. With
Axiom 1.2.13 that didn't cause problems, but 1.2.14 is less lenient,
causing an error as described in AXIOM-463.

This change:
* Updates the StreamingPayload documentation to specify that the
namespace prefix in the QName returned by getName() has no significance
(which is effectively how things are currently).
* Updates AxiomSoapBody so that it Axiom is aware that the namespace
prefix of the created OMSourcedElement is unknown.
* Modifies the unit test for setStreamingPayload so that it uses a
StreamingPayload with a prefix mismatch.
@gregturn
Copy link
Contributor

@veithen I've walked through this PR. I ran it as well as the master branch, both against Axiom 1.2.13 and 1.2.14. I don't see any breaking change to expose the issue at hand. Is there an additional test case we need to expose the fault you are citing?

@veithen
Copy link
Contributor Author

veithen commented Jul 15, 2015

The PR generalizes an existing test case to expose the problem. If you only apply the part of the change that modifies AbstractSoapMessageTestCase, then you can reproduce the failure.

@gregturn
Copy link
Contributor

Thanks. I can poke at this some more next week.

@mdiskin
Copy link

mdiskin commented Dec 10, 2015

Still getting this error any update when this PR can be released? I have support with VMware/pivotal if you need me to report it that channel to help get it bumped in priority.

@gregturn
Copy link
Contributor

Resolved via 1d9a6b5. Thanks!

@gregturn gregturn closed this Dec 15, 2015
@veithen veithen deleted the AXIOM-463 branch December 19, 2015 16:14
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

Successfully merging this pull request may close these issues.

None yet

3 participants