JAXB SOAP Client and Mock Endpoint: Default Namespace Inheritance Across Metro and MOXy
0 reputation · 08 Jun 2023, 21:33 UTC
0 reputation · 08 Jun 2023, 21:33 UTC
When a JAXB-mapped SOAP client is pointed at a mock HTTP endpoint for integration testing without production credentials, the transport layer can be redirected without altering binding code. However, if the mock response omits a default namespace declaration that the real service would include, unmarshalling behavior may become implementation-dependent.
Metro and EclipseLink MOXy are reported to differ in whether child elements inherit an implicit namespace from an ancestor when the declaration is absent, causing the same fixture to produce different object graphs. This raises a design question about whether the mock should reproduce the exact namespace structure of the production WSDL or whether the client must be explicitly configured to tolerate missing declarations.
Is the divergence a documented JAXB specification gap, a configurable parser feature, or an artifact of how the mock serializes the SOAP envelope? Which namespace resolution strategy should govern the test fixture when the goal is to mirror production parsing without accessing live credentials?
32275 reputation · 09 Jun 2023, 03:46 UTC
When the transport layer is redirected to a mock HTTP endpoint without altering JAXB binding code, any divergence between Metro and MOXy should first be treated as a fixture serialization and namespace-URI mismatch—not as a documented JAXB specification gap or a supported provider-specific namespace-inheritance feature. The mock must reproduce the exact namespace structure of the production WSDL, because the client’s mappings are keyed to namespace URIs that the real service would emit.
XML namespace scoping is deterministic: a default xmlns declaration is inherited by descendant elements only while it is in scope. If the mock omits it, descendants are in no namespace. JAXB mappings keyed to a namespace URI do not receive an implicit ancestor namespace. The XML infoset for identical response bytes is identical across parsers; therefore Metro and MOXy should observe the same namespace URIs and local names for the same fixture.
Metro and MOXy may differ in leniency, provider wiring, SOAP-version handling, schema validation, or handling of unexpected namespaces, but these are implementation or configuration artifacts—not a specification gap. Behavior is version- and configuration-sensitive; avoid generalizing from a single fixture.
Mirror production namespace structure, not prefixes:
xmlns declarations on the same ancestors.elementFormDefault qualification as the XSD.ns1 versus a default prefix is irrelevant if URIs match.Do not configure the client to tolerate missing declarations as the primary fix; that hides contract mismatches. Use normalization only as a temporary diagnostic or when the production contract truly permits optional qualification.
xmlns.elementFormDefault settings as the client, then unmarshal without HTTP.To choose the correct fix, determine whether the failing child element is unprefixed with no default xmlns in scope, or prefixed with a namespace URI different from the mapped namespace. The first requires restoring the declaration; the second requires correcting the URI.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.