What I have found out though is the following, The 
class(com.sample.test.webservices.impl.participant.Notify.class) is question is 
for a one way operation (notify). The wsdl for that operation looks like:

<wsdl:operation name="notify">
            <wsdl:input message="ns:notifyRequest" 
wsaw:Action="urn:coretest:ParticipantService#notify"/>
            <wsdl:output message="ns:null" wsaw:Action="urn:notifyResponse"/>
            <wsdl:fault message="ns:RecoverableFault" name="RecoverableFault" 
wsaw:Action="urn:notifyRecoverableFault"/>
            <wsdl:fault message="ns:UnrecoverableFault" 
name="UnrecoverableFault" wsaw:Action="urn:notifyUnrecoverableFault"/>
        </wsdl:operation>

<wsdl:operation name="notify">
            <soap12:operation 
soapAction="urn:coretest:ParticipantService#notify" style="document"/>
            <wsdl:input>
                <soap12:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap12:body use="literal"/>
            </wsdl:output>
            <wsdl:fault name="UnrecoverableFault">
                <soap12:fault use="literal" name="UnrecoverableFault"/>
            </wsdl:fault>
            <wsdl:fault name="RecoverableFault">
                <soap12:fault use="literal" name="RecoverableFault"/>
            </wsdl:fault>
        </wsdl:operation>
If I remove the output and the fault messages from the operation, I do not see 
the same issue.

<wsdl:operation name="notify">
            <wsdl:input message="ns:notifyRequest" 
wsaw:Action="urn:coretest:ParticipantService#notify"/>
        </wsdl:operation>

And
<wsdl:operation name="notify">
            <soap:operation soapAction="urn:coretest:ParticipantService#notify" 
style="document"/>
            <wsdl:input>
                <soap:body use="literal"/>
            </wsdl:input>
        </wsdl:operation>

However, some of the other wsdls that have the same operation along with the 
output and fault messages work fine. So the behavior seems extremely strange to 
me.

Thanks
Sumit


From: Shah, Sumit (CGI Federal)
Sent: Wednesday, March 20, 2013 10:43 PM
To: java-user@axis.apache.org
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 is precisely what I am trying to find out why it is adding the comma after 
the last class parameter.


Thanks
Sumit

From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Wednesday, March 20, 2013 7:49 PM
To: java-user@axis.apache.org<mailto:java-user@axis.apache.org>
Subject: RE: WSImport w JDK 1.6.0_25 and Axis2 1.6.2: Generated stub fails 
compilation

com.sample.test.webservices.impl.participant.Notify.class,

reason why the last class parameter has a trailing comma

Martin

From: Shah, Sumit (CGI Federal)
Sent: Wednesday, March 20, 2013 6:20 PM
To: java-user@axis.apache.org<mailto:java-user@axis.apache.org>
Subject: RE: WSImport w JDK 1.6.0_25 and Axis2 1.6.2: Generated stub fails 
compilation - Update: Actually issue occurring in WSDL2Code

I did some research and it's the code/XSL in JaxbRIDatabindingTemplate.xsl that 
is writing out the portion of the stub that causing the compilation issue. 
Unless a concurrency issue, I wonder why consistently in couple of cases the 
'position() != last()' seems to be 'true' when it should be false. And hence 
the additional comma at the end of the last element in the array. I would 
appreciate any pointers.

'
        private static final javax.xml.bind.JAXBContext wsContext;
        static {
            javax.xml.bind.JAXBContext jc;
            jc = null;
            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>
                           );
            }
            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;
                     }
        }
'
Thanks
Sumit

From: Shah, Sumit (CGI Federal)
Sent: Wednesday, March 20, 2013 3:27 PM
To: java-user@axis.apache.org<mailto:java-user@axis.apache.org>
Subject: RE: WSImport w JDK 1.6.0_25 and Axis2 1.6.2: Generated stub fails 
compilation - Update: Actually issue occurring in WSDL2Code

I take the WSImport part back. It is actually happening with WSDL2Code. It does 
not happen if I use the WSDL2Code with Axis2 1.6.0.

The issue is happening with WSDL2Code in Axis2 1.6.2 and I am using Axiom 
1.2.14. Is anyone aware of the issue with 1.6.2?

From: Shah, Sumit (CGI Federal)
Sent: Wednesday, March 20, 2013 11:22 AM
To: java-user@axis.apache.org<mailto:java-user@axis.apache.org>
Subject: WSImport w JDK 1.6.0_25 and Axis2 1.6.2: Generated stub fails 
compilation

Hi,

I am using WSImport to generate the client stubs for a bunch of wsdl files. 
After the generation the code fails to compile. I am using this with Axis2 
1.6.2. The following code block fails:

If you notice: the line: 
'com.sample.test.webservices.impl.participant.Notify.class,' ends with a comma 
that shouldn't be there. Ironically it only happens for 2 of the 10 or so wsdl 
files I have.  Any information would be appreciated.

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;
                                                }
        }

Reply via email to