[
https://issues.apache.org/jira/browse/CXF-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated CXF-1198:
----------------------------------
Description:
I made a change to the classes for the Javascript test harness service, and I
hit an apparently unrelated problem.
If you remove the @Ignore from DocLitWrappedTest, and run with -ea, you'll hit
an assertion. The assertion is because there is a type with an element with no
schema type, no schema type name, and a refName of {}testBean1. Now, there's no
such beast. Really. testBean1 derives from the class TestBean1, which looks
like ...
@XmlRootElement
@XmlType(namespace = "uri:org.apache.cxf.javascript.testns")
public class TestBean1
The result of adding an XmlRootElement without a namespace is to create an
element in no namespace! However, nothing sets up the XmlSchema for the
nameless namespace, leading to confusion in the service model later on.
was:
I made a change to the classes for the Javascript test harness service, and I
hit an apparently unrelated problem.
If you remove the @Ignore from DocLitWrappedTest, and run with -ea, you'll hit
an assertion. The assertion is because there is a type with an element with no
schema type, no schema type name, and a refName of {}testBean1. Now, there's no
such beast. Really. testBean1 derives from the class TestBean1, which looks
like ...
@XmlRootElement
@XmlType(namespace = "uri:org.apache.cxf.javascript.testns")
public class TestBean1
In the past, I hit some cases like this where the XML Schema objects were more
or less acting like a faithful recording of what the XML might look like:
ref='bloop' for bloop in the TNS. Whether or not that's a good idea, it isn't
what's happening this time, in that the type that contains the element that
causes this havoc lives in a different namespace than the TestBean1, so in XML
the ref would have an actual prefix.
Dan may already be 'in process' on this issue, I don't know why adding a
wrapper type to enable something else entirely uncovered this particular
manifestation.
Summary: JAXB does not maintain the unqualified namespace (was:
Element with a refName pointing to an unqualified element that isn't in the
same schema.)
> JAXB does not maintain the unqualified namespace
> ------------------------------------------------
>
> Key: CXF-1198
> URL: https://issues.apache.org/jira/browse/CXF-1198
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
> Affects Versions: 2.1
> Reporter: Benson Margulies
> Assignee: Daniel Kulp
> Attachments: diffs.txt
>
>
> I made a change to the classes for the Javascript test harness service, and I
> hit an apparently unrelated problem.
> If you remove the @Ignore from DocLitWrappedTest, and run with -ea, you'll
> hit an assertion. The assertion is because there is a type with an element
> with no schema type, no schema type name, and a refName of {}testBean1. Now,
> there's no such beast. Really. testBean1 derives from the class TestBean1,
> which looks like ...
> @XmlRootElement
> @XmlType(namespace = "uri:org.apache.cxf.javascript.testns")
> public class TestBean1
> The result of adding an XmlRootElement without a namespace is to create an
> element in no namespace! However, nothing sets up the XmlSchema for the
> nameless namespace, leading to confusion in the service model later on.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
