You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Steve Green <st...@epok.net> on 2005/07/22 00:00:44 UTC
Even more symbolTable woes?
Developers,
I've just run across another problem with the head of CVS as it pertains
to W2j. The following xsd snippet is cut down from
http://www.w3.org/2000/09/xmldsig#
<complexType name="ReferenceType">
<sequence>
<element ref="ds:DigestValue"/>
</sequence>
</complexType>
<element name="DigestValue" type="ds:DigestValueType"/>
<simpleType name="DigestValueType">
<restriction base="base64Binary"/>
</simpleType>
Once upon a time, the bean metadata for the DigestValue element looked
like this:
elemField.setXmlName(
new javax.xml.namespace.QName(
"http://www.w3.org/2000/09/xmldsig#", "DigestValue"));
elemField.setXmlType(
new javax.xml.namespace.QName(
"http://www.w3.org/2001/XMLSchema", "base64Binary"));
But now it looks like this:
elemField.setXmlName(
new javax.xml.namespace.QName(
"http://www.w3.org/2000/09/xmldsig#", "DigestValue"));
elemField.setXmlType(
new javax.xml.namespace.QName(
"http://www.w3.org/2000/09/xmldsig#", "DigestValue"));
And as a result, I get this:
org.xml.sax.SAXException: Found character data inside an array element
while deserializing
Hand editing the generated code gets me past the problem. Before I dive
into this and potentially create a bug report, does anyone recognize
this as a known problem?
~S
Re: Even more symbolTable woes?
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to report a new one with this info.
-- dims
On 7/22/05, Steve Green <st...@epok.net> wrote:
> On Thu, 2005-07-21 at 18:29 -0400, Davanum Srinivas wrote:
> > not a known problem. please dive in.
> >
> > -- dims
>
> I dived in but I am not in too deep yet. It looks like the problem is
> in JavaBeanHelperWriter and came as the result of:
>
> revision 1.50
> date: 2005/03/20 18:58:49; author: gdaniels; state: Exp;
> lines: +6 -7
> branches: 1.50.2;
> Fix:
>
> http://issues.apache.org/jira/browse/AXIS-1869
>
> Don't walk the ref chain unless the TypeEntry is a CollectionTE
> - this should DTRT for true derived types.
>
> Specifically,
>
> // Otherwise, use the type at the end of the ref
> // chain.
> while (elemType.getRefType() != null) {
> elemType = elemType.getRefType();
> }
>
> was changed to
>
> // Otherwise, use the first non-Collection type we
> // encounter up the ref chain.
> while (elemType instanceof CollectionTE) {
> elemType = elemType.getRefType();
> }
>
> At this point, I am quickly reaching the depth of my understanding as to
> what it going on here. Anyone (glen) want to shed some light?
>
> Does it make sense to reopen/back-out AXIS-1869 or shall I create a new
> report?
>
> ~S
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Even more symbolTable woes?
Posted by Steve Green <st...@epok.net>.
On Thu, 2005-07-21 at 18:29 -0400, Davanum Srinivas wrote:
> not a known problem. please dive in.
>
> -- dims
I dived in but I am not in too deep yet. It looks like the problem is
in JavaBeanHelperWriter and came as the result of:
revision 1.50
date: 2005/03/20 18:58:49; author: gdaniels; state: Exp;
lines: +6 -7
branches: 1.50.2;
Fix:
http://issues.apache.org/jira/browse/AXIS-1869
Don't walk the ref chain unless the TypeEntry is a CollectionTE
- this should DTRT for true derived types.
Specifically,
// Otherwise, use the type at the end of the ref
// chain.
while (elemType.getRefType() != null) {
elemType = elemType.getRefType();
}
was changed to
// Otherwise, use the first non-Collection type we
// encounter up the ref chain.
while (elemType instanceof CollectionTE) {
elemType = elemType.getRefType();
}
At this point, I am quickly reaching the depth of my understanding as to
what it going on here. Anyone (glen) want to shed some light?
Does it make sense to reopen/back-out AXIS-1869 or shall I create a new
report?
~S
Re: Even more symbolTable woes?
Posted by Davanum Srinivas <da...@gmail.com>.
not a known problem. please dive in.
-- dims
On 7/21/05, Steve Green <st...@epok.net> wrote:
> Developers,
>
> I've just run across another problem with the head of CVS as it pertains
> to W2j. The following xsd snippet is cut down from
> http://www.w3.org/2000/09/xmldsig#
>
> <complexType name="ReferenceType">
> <sequence>
> <element ref="ds:DigestValue"/>
> </sequence>
> </complexType>
>
> <element name="DigestValue" type="ds:DigestValueType"/>
>
> <simpleType name="DigestValueType">
> <restriction base="base64Binary"/>
> </simpleType>
>
> Once upon a time, the bean metadata for the DigestValue element looked
> like this:
>
> elemField.setXmlName(
> new javax.xml.namespace.QName(
> "http://www.w3.org/2000/09/xmldsig#", "DigestValue"));
> elemField.setXmlType(
> new javax.xml.namespace.QName(
> "http://www.w3.org/2001/XMLSchema", "base64Binary"));
>
> But now it looks like this:
>
> elemField.setXmlName(
> new javax.xml.namespace.QName(
> "http://www.w3.org/2000/09/xmldsig#", "DigestValue"));
> elemField.setXmlType(
> new javax.xml.namespace.QName(
> "http://www.w3.org/2000/09/xmldsig#", "DigestValue"));
>
> And as a result, I get this:
>
> org.xml.sax.SAXException: Found character data inside an array element
> while deserializing
>
> Hand editing the generated code gets me past the problem. Before I dive
> into this and potentially create a bug report, does anyone recognize
> this as a known problem?
>
> ~S
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/