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 "Boyan Yurukov (JIRA)" <ji...@apache.org> on 2007/09/24 15:00:50 UTC
[jira] Created: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Axis2 does not understand XSD substitutionGroup
-----------------------------------------------
Key: AXIS2-3224
URL: https://issues.apache.org/jira/browse/AXIS2-3224
Project: Axis 2.0 (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
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 this type "OneTypeExtension", so the last can contain the type java class and not the elements 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 so:
...
<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 that case each 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 of the class itself. However, what I did so far 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Posted by "Boyan Yurukov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Yurukov updated AXIS2-3224:
---------------------------------
Description:
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.
was:
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 this type "OneTypeExtension", so the last can contain the type java class and not the elements 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 so:
...
<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 that case each 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 of the class itself. However, what I did so far 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.
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.3, 1.2
> Environment: WinXP, axis2 1.3 snapshot 21.09.2007
> Reporter: Boyan Yurukov
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Posted by "Boyan Yurukov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Yurukov updated AXIS2-3224:
---------------------------------
Attachment: gened_code.zip
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.3, 1.2
> Environment: WinXP, axis2 1.3 snapshot 21.09.2007
> Reporter: Boyan Yurukov
> 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 this type "OneTypeExtension", so the last can contain the type java class and not the elements 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 so:
> ...
> <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 that case each 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 of the class itself. However, what I did so far 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Posted by "Boyan Yurukov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Yurukov updated AXIS2-3224:
---------------------------------
Attachment: one.wsdl
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.3, 1.2
> Environment: WinXP, axis2 1.3 snapshot 21.09.2007
> Reporter: Boyan Yurukov
> Attachments: 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 this type "OneTypeExtension", so the last can contain the type java class and not the elements 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 so:
> ...
> <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 that case each 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 of the class itself. However, what I did so far 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Posted by "Boyan Yurukov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Yurukov updated AXIS2-3224:
---------------------------------
Attachment: someschema.xsd
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.3, 1.2
> Environment: WinXP, axis2 1.3 snapshot 21.09.2007
> Reporter: Boyan Yurukov
> Attachments: 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 this type "OneTypeExtension", so the last can contain the type java class and not the elements 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 so:
> ...
> <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 that case each 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 of the class itself. However, what I did so far 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Posted by "Boyan Yurukov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Yurukov updated AXIS2-3224:
---------------------------------
Attachment: azis2_gen_server.bat
axis2_gen_server.bat is the command I used to generate the service. It is pretty standard. I have also attached the generated code I got.
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.3, 1.2
> Environment: WinXP, axis2 1.3 snapshot 21.09.2007
> Reporter: Boyan Yurukov
> 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 this type "OneTypeExtension", so the last can contain the type java class and not the elements 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 so:
> ...
> <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 that case each 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 of the class itself. However, what I did so far 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-3224) Axis2 does not understand XSD
substitutionGroup
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-3224:
----------------------------------------
Assignee: Amila Chinthaka Suriarachchi
> Axis2 does not understand XSD substitutionGroup
> -----------------------------------------------
>
> Key: AXIS2-3224
> URL: https://issues.apache.org/jira/browse/AXIS2-3224
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb, codegen
> Affects Versions: 1.3, 1.2
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org