[
https://issues.apache.org/jira/browse/AXIS2-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumit Shah updated AXIS2-5505:
------------------------------
Attachment: ParticipantService.wsdl
WSDL that causes the issue
> WSDL2Code/Axis2 1.6.2: Generated Stub fails compilation - Possible issue in
> JaxbRIDatabindingTemplate.xsl
> ---------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-5505
> URL: https://issues.apache.org/jira/browse/AXIS2-5505
> Project: Axis2
> Issue Type: Bug
> Components: codegen
> Affects Versions: 1.6.2
> Environment: Windows 7 - 64 bit, Weblogic 11gR1 & JDK 1.6.0_25
> Reporter: Sumit Shah
> Priority: Critical
> Attachments: ParticipantService.wsdl
>
>
> I am using WSDL2Code in Axis2 1.6.2 to generate the client stubs from a set
> of WSDLs. However, the following code block fails compilation in couple of
> the WSDL files. If you notice: the line:
> 'com.sample.test.webservices.impl.participant.Notify.class,' ends with a
> comma that shouldn't be there.
> try {
> jc = javax.xml.bind.JAXBContext.newInstance(
> <xsl:for-each select="param[not(@type =
> preceding-sibling::param/@type)]">
> <xsl:if test="@type!=''">
> <xsl:value-of select="@type"/>.class<xsl:if
> test="position() != last()">,
> </xsl:if>
> </xsl:if>
> </xsl:for-each>
> );
> }
> If I remove the <wsdl:output> and the faults from the <wsdl:operation>, I do
> not see this issue.
> It seems like the XSL needs to be fixed to account for such operations.
> Below is the snippet of the generated stub:
> private static final javax.xml.bind.JAXBContext wsContext;
> static {
> javax.xml.bind.JAXBContext jc;
> jc = null;
> try {
> jc =
> javax.xml.bind.JAXBContext.newInstance(
> com.sample.test.webservices.impl.participant.Add.class,
>
> com.sample.test.webservices.impl.participant.AddResponse.class,
>
> com.sample.test.webservices.exceptions.UnrecoverableFault.class,
>
> com.sample.test.webservices.exceptions.RecoverableFault.class,
>
> com.sample.test.webservices.impl.participant.Delete.class,
>
> com.sample.test.webservices.impl.participant.DeleteResponse.class,
>
> com.sample.test.webservices.impl.participant.Select.class,
>
> com.sample.test.webservices.impl.participant.SelectResponse.class,
>
> com.sample.test.webservices.impl.participant.AddChange.class,
>
> com.sample.test.webservices.impl.participant.AddChangeResponse.class,
>
> com.sample.test.webservices.impl.participant.Query.class,
>
> com.sample.test.webservices.impl.participant.QueryResponse.class,
>
> com.sample.test.webservices.impl.participant.Update.class,
>
> com.sample.test.webservices.impl.participant.UpdateResponse.class,
>
> com.sample.test.webservices.impl.participant.Change.class,
>
> com.sample.test.webservices.impl.participant.ChangeResponse.class,
>
> com.sample.test.webservices.impl.participant.Synchronize.class,
>
> com.sample.test.webservices.impl.participant.SynchronizeResponse.class,
>
> com.sample.test.webservices.impl.participant.Notify.class,
>
> );
> }
> catch ( javax.xml.bind.JAXBException ex ) {
> System.err.println("Unable to create JAXBContext: " +
> ex.getMessage());
> ex.printStackTrace(System.err);
> Runtime.getRuntime().exit(-1);
> }
> finally {
> wsContext = jc;
> }
> }
> This issue does not occur in 1.6.0.
> Research so far
> -------------------------------------------------------------
> https://issues.apache.org/jira/browse/AXIS2-5215 caused the Java2WSDL change
> from 1.6.0 to 1.6.2. If you notice the wsdl change I mention below, in that
> case I see why the JaxbRIDatabindingTemplate.xsl is failing. This is a guess,
> but FWIW…the wsdl generated for a one way operation using Java2WSDL contains
> a ‘null’ message for the output as shown below:
> <wsdl:operation name="notify">
> <wsdl:input message="ns:notifyRequest"
> wsaw:Action="urn:coretest:ParticipantService#notify"/>
> <wsdl:output message="ns:null" wsaw:Action="urn:notifyResponse"/>
> <!—This is what I refer to-->
> <wsdl:fault message="ns:RecoverableFault" name="RecoverableFault"
> wsaw:Action="urn:notifyRecoverableFault"/>
> <wsdl:fault message="ns:UnrecoverableFault"
> name="UnrecoverableFault" wsaw:Action="urn:notifyUnrecoverableFault"/>
> </wsdl:operation>
> If you look at the wsdl snippet above and the code in the
> JaxbRIDatabindingTemplate.xsl, after writing Notify.class, (because probably
> at that point in the order Notify.class is not the last one) and is expecting
> to write NotifyResponse.class as the last one, but the check ‘<xsl:if
> test="@type!=''">’ fails because the output message/type is null and hence
> the trailing comma.
>
> try {
> jc = javax.xml.bind.JAXBContext.newInstance(
> <xsl:for-each select="param[not(@type =
> preceding-sibling::param/@type)]">
> <xsl:if test="@type!=''">
> <xsl:value-of select="@type"/>.class<xsl:if
> test="position() != last()">,
> </xsl:if>
> </xsl:if>
> </xsl:for-each>
> );
> }
> If I remove the <wsdl:output> and the faults from the <wsdl:operation>, I do
> not see this issue.
> It seems like the XSL needs to be fixed to account for such operations.
> Email Snippet from Andreas
> ------------------------------------------------------
> -----Original Message-----
> From: Andreas Veithen [mailto:[email protected]]
> Sent: Thursday, March 21, 2013 4:35 AM
> To: java-user
> Subject: Re: WSImport w JDK 1.6.0_25 and Axis2 1.6.2: Generated stub fails
> compilation - Update: Actually issue occurring in WSDL2Code
> That's simply because the code in JaxbRIDatabindingTemplate.xsl is incorrect.
> position() != last() checks if the current node is the last node, but the
> expression appears in an <xsl:if> block. So, if the last node doesn't satisfy
> the condition of the <xsl:if> block, then an extra comma is generated and the
> generated code won't compile.
> Andreas
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
