[
https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972872#comment-13972872
]
Mark Thijssen commented on AXIS2-3224:
--------------------------------------
This is still an issue in version 1.6.2.
Also the webservice gets into an infinite loop when it receives a message
formatted like the first example in the description even though the messages
validates perfectly with the XSD.
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis2
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.2, 1.3
> Environment: WinXP, axis2 1.3 snapshot 21.09.2007
> Reporter: Boyan Yurukov
> Assignee: Amila Chinthaka Suriarachchi
> Attachments: azis2_gen_server.bat, gened_code.zip, one.wsdl,
> someschema.xsd
>
>
> I have attached a sample schema and a wsdl. In them there is a couple of
> elements that are in the same substitutionGroup as "SomeElementZero". Also we
> have a list "SomeElementList" which can hold "SomeElementZero"-s. It should
> be possible to insert all the rest elements from the substitutionGroup in the
> list, but effectively that does not happen. What the generated java code
> should serialize/parse as follows:
> ...
> <inner:SomeElementZero>
> <some:SomeElementZero data="bla bla bla" />
> <some:SomeElement1 data="bla bla bla" data1="more bla 1"/>
> <some:SomeElement2 data="bla bla bla" data1="more bla 2"/>
> <some:SomeElement2 data="bla bla bla" data1="more bla 2"/>
> </inner:SomeElementZero>
> ...
> And probably xsi:type for each subelement.
> However in the generated code, the java class that is responsible for
> "SomeElementList" can hold a list of "OneType" which is the type of
> "SomeElementZero". Of course the other elements are of a type that is an
> extension of "OneType" or namely "OneTypeExtension", so the list can contain
> the type java classes and not the element java classes themselves. Since the
> list java class knows that it can contain only "SomeElementZero", it assumes
> that when serializing/parsing. In that case the code would serialize to
> something like this:
> ...
> <inner:SomeElementZero>
> <some:SomeElementZero data="bla bla bla" xsi:type="some:OneType"/>
> <some:SomeElementZero data="bla bla bla" data1="more bla 1"
> xsi:type="some:OneTypeExtension"/>
> <some:SomeElementZero data="bla bla bla" data1="more bla 2"
> xsi:type="some:OneTypeExtension"/>
> <some:SomeElementZero data="bla bla bla" data1="more bla 2"
> xsi:type="some:OneTypeExtension"/>
> </inner:SomeElementZero>
> ...
> One workarround is to define all those types as local for the elements in the
> schema. In that case one can put element java objects in the list. Still one
> has to change the code since when we serialize the list, it calls directly
> the "serialize" method of the subelements and passes the qname
> "SomeElementZero". We have to set it to call the *.getOMElement().serialize(
> xmlWriter ), which would take the local qname (which is right).
> However, what I did so far, since I didn't what to change the schema, was to
> change the list java class to be able to hold the element implementation, to
> detect their type and to serialize them accordingly.
> There are similar problems in parsing.
> This explanation may be somewhat blurry, but the case is very specific and
> hard to explain. Please check the attached files for examples.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
