Hi Doug,
The WS-BasicProfile 1.1 spec is pretty clear on this interoperability
requirement,
R2301 The order of the elements in the soap:body of an ENVELOPE MUST be the
same as that of the wsdl:parts in the wsdl:message that describes it.
but also says,
R2302 A DESCRIPTION MAY use the parameterOrder attribute of an
wsdl:operation element to indicate the return value and method signatures as
a hint to code generators.
so let's try this; can you change the operation:
<operation name="listInstances">
<input message="tns:listInstancesInput"/>
<output message="tns:listInstancesOutput"/>
<fault name="ManagementFault" message="tns:managementFault"/>
</operation>
to,
<operation name="listInstances" parameterOrder="filter order limit">
<input message="tns:listInstancesInput"/>
<output message="tns:listInstancesOutput"/>
<fault name="ManagementFault" message="tns:managementFault"/>
</operation>
And see if that helps?
alex
On 1/24/08, Jackson, Douglas <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
>
>
> I doubt this is a problem with the wsdl file, but when I run the
> following:
>
>
>
> d:\axis2-1.3\bin\wsdl2java.bat -o code -S src -t -R resource -uri
> pmapi.wsdl
>
>
>
> It produces a InstanceManagementServiceStub class that generates xml
> with some of the parameters in the wrong order. For instance, the
> ListInstances subclass has a serialize method that outputs the
> parameters in this order: filter, limit, order.
>
> The Axis2 ManagementService then chokes with an error saying it cannot
> convert order into an integer, and if you set order to an integer then
> the ProcessAndInstanceManagement class complains because order should be
> "pid, ... ".
>
> If I reorder the serialize code to spit out the parameters in the
> correct order then everything works.
>
> I dislike having to edit the generated file however, so if there is
> something that can be done to fix in the wsdl file I would like to get
> my hands on it. Perhaps some sort of parameter order on the binding?
>
>
>
> ListEvents had the same issue with it's serialize method. I have not
> tried all of the endpoints.
>
>
>
> I also ran into an exception on the ListEvents when passing in empty
> strings for the filters. An empty string worked for a filter on
> ListInstances so is this a bug?
>
>
>
> DEBUG - GeronimoLog.debug(66) | Received mgmt message for
> InstanceManagement.{http://www.apache.org/ode/pmapi}listEvents
>
> DEBUG - GeronimoLog.debug(66) | Extracting param class java.lang.String
> from <eventFilter />
>
> DEBUG - GeronimoLog.debug(66) | Extracting param class java.lang.String
> from <instanceFilter />
>
> DEBUG - GeronimoLog.debug(66) | Extracting param int from
> <maxCount>100</maxCount>
>
> ERROR - GeronimoLog.error(108) | Exception during database operation
>
> java.lang.UnsupportedOperationException
>
> at
> org.apache.ode.dao.jpa.BPELDAOConnectionImpl.bpelEventQuery(BPELDAOConne
> ctionImpl.java:67)
>
> at
> org.apache.ode.bpel.engine.ProcessAndInstanceManagementImpl$7.run(Proces
> sAndInstanceManagementImpl.java:469)
>
> at
> org.apache.ode.bpel.engine.BpelDatabase$1.call(BpelDatabase.java:80)
>
> at
> org.apache.ode.bpel.engine.Contexts.execTransaction(Contexts.java:105)
>
> at
> org.apache.ode.bpel.engine.BpelDatabase.exec(BpelDatabase.java:78)
>
> at
> org.apache.ode.bpel.engine.ProcessAndInstanceManagementImpl.dbexec(Proce
> ssAndInstanceManagementImpl.java:587)
>
> at
> org.apache.ode.bpel.engine.ProcessAndInstanceManagementImpl.listEvents(P
> rocessAndInstanceManagementImpl.java:467)
>
>
>
>
>
> -Doug
>
>
