Hello Scott,
There are still a bunch of errors in your WSDL and XSD files.
Maybe they are not related to the problems you are encountering, but it
is also possible that Axis is choking on them and generates incorrect files.
#The first problem I noticed was that you put <attribute>s before
<sequence> in <complexType>s.
Why don't you google for a WSDL and an XML validator and sort them out
first?
On the WS-I web site there is also a Java-based tool to check whether
your WSDL is WS-I BP compliant (it does not check everything, though).
I believe the WS-I test tool does not XML validate files.
I sometimes use Cape Clear's SOA editor for validating WSDL files, but
never got it to check imported WSDL/XSD files.
If you find a good all-in-one checking tool, please let me know.
Regards,
Dies
Scott McCoy wrote:
---------- Forwarded message ----------
From: Scott McCoy <[EMAIL PROTECTED]>
Date: Mar 2, 2006 11:33 AM
Subject: Re: WSDD2Java + Admin util for deployment = Undescribably strange
error...
To: [EMAIL PROTECTED]
I've discovered that relying on the SOAPAction header does not comply with
WS-I Standards, but when trying to move to the wrapped document literal
syntax, where I have a different document element for each method, I
suddenly am not able to properly include my soap header elements.
I tried using your suggestion here, attached is a little stub where I tried
to do so, using what seems to be your suggestions here. Using another form
I was able to get the header element included but that does not unwrap my
createAccount method, and I'm unsure as to if it will properly map to the
correct method.
When trying to simply omit the soapaction attribute from the operation
definitions in my previous binding, axis just sort of stops working.
Any input would be appreciated,
Thanks,
Scott S. McCoy
On 2/22/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
Scott, there are a bunch of errors in your WSDL. I've corrected a few of
them (including notes about the corrections in comments):
<wsdl:definitions name="urn:Account"
targetNamespace=" http://plm.marchex.com/service/account";
xmlns:tns=" http://plm.marchex.com/service/account "
xmlns:typens="http://plm.marchex.com/service/account";
xmlns:authns=" http://plm.marchex.com/credentials "
<!-- wrong version of XML Schema
xmlns:xsd="http://www.w3.org/1999/XMLSchema "
-->
xmlns:xsd=" http://www.w3.org/2001/XMLSchema";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/ "
xmlns:wsdl=" http://schemas.xmlsoap.org/wsdl/";>
<wsdl:types>
<!-- Use xsd:import or xsd:include to import xsd definitions -->
<xsd:schema targetNamespace="http://plm.marchex.com/services/account
">
<xsd:include schemaLocation="account.xsd"/>
<xsd:import namespace=" http://plm.marchex.com/credentials "
schemaLocation="credentials.xsd"/>
</xsd:schema>
</wsdl:types>
<!-- Use wsdl:import only to import wsdl files
<wsdl:import namespace=" http://plm.marchex.com/service/account";
location="account.xsd"/>
<wsdl:import namespace=" http://plm.marchex.com/credentials";
location="credentials.xsd"/>
-->
<!-- If you want to use the wrapped convention, then you must define a
different set of request and response messages for each operation.
The element referenced by the input message part must be a
"wrapper" element that has the same name as the operation. If you
prefer to not use the wrapped convention, you still must define a
unique input message for operation becuase the input element for
each operation must have a unique name.
-->
<wsdl:message name="CredentialsOnly">
<wsdl:part name="credentials" element="authns:credentials"/>
</wsdl:message>
<wsdl:message name="AccountList">
<wsdl:part name="accounts" element="tns:accounts"/>
</wsdl:message>
<-- You don't need to include the "credentials" part in each of your
messages. You can reference the "CredentialsOnly" message for
your header elements. (Definitely cleaner if you want to use the
same header in multiple messages.)
-->
<wsdl:message name="AccountDetails">
<wsdl:part name="credentials" element="authns:credentials"/>
<wsdl:part name="account" element="tns:account"/>
</wsdl:message>
<wsdl:message name="UserDetails">
<wsdl:part name="credentials" element="authns:credentials"/>
<wsdl:part name="user" element="tns:user"/>
</wsdl:message>
<!-- we need to return a different message than we accept -->
<wsdl:message name="AccountResponse">
<wsdl:part name="accountlist" element="tns:account"/>
</wsdl:message>
<wsdl:message name="UserResponse">
<wsdl:part name="userlist" element="tns:user"/>
</wsdl:message>
<wsdl:message name="empty"/>
<wsdl:portType name="AccountPortType">
<wsdl:operation name="createAccount">
<wsdl:input message="tns:AccountDetails"/>
<wsdl:output message="tns:AccountResponse"/>
</wsdl:operation>
<!-- When using document style, each input message must be unique.
You must define different input messages for createAccount,
updateAccount, and cancelAccount. I suggest you follow the
wrapped convention (create a wrapper element for each operation
in which the wrapper element has the same name as the operation).
-->
<wsdl:operation name="updateAccount">
<wsdl:input message="tns:AccountDetails"/>
<wsdl:output message="tns:empty"/>
</wsdl:operation>
<wsdl:operation name="listAccounts">
<wsdl:input message="tns:CredentialsOnly"/>
<wsdl:output message="tns:AccountList"/>
</wsdl:operation>
<wsdl:operation name="cancelAccount">
<wsdl:input message="tns:AccountDetails"/>
<wsdl:output message="tns:empty"/>
</wsdl:operation>
<wsdl:operation name="createUser">
<wsdl:input message="tns:UserDetails"/>
<wsdl:output message="tns:UserResponse"/>
</wsdl:operation>
<wsdl:operation name="updateUser">
<wsdl:input message="tns:UserDetails"/>
<wsdl:output message="tns:empty"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="AccountSOAPBinding" type="tns:AccountPortType">
<!-- There's no such WSDL style as "wrapped". Wrapped is simply a
convention
for document/literal that produces an RPC-like programming
interface.
<soap:binding style="wrapped"
transport="http://schemas.xmlsoap.org/soap/http"/>
-->
<soap:binding style="document"
transport=" http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="createAccount">
<soap:operation soapAction="createAccount"/>
<wsdl:input>
<!-- In theory, this should explicitly specify the following
goes
through the Header only -->
<!-- soap:body definition must appear before the soap:header definition
soap:body uses the "parts" attribute rather than the "part"
attribute
(the "parts" attribute would not be necessary if you didn't define
the
"credentials" part in each of your input messages)
soap:header requires an additional "message" attribute (the header
can be defined in a separate message)
<soap:header use="literal" part="credentials"/>
<soap:body use="literal" part="account"/>
-->
<soap:body use="literal" parts="account"/>
<soap:header message="tns:AccountDetails" use="literal"
part="credentials"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<!-- Make comparable changes to the other bindings -->
Regards,
Anne
On 2/22/06, Scott McCoy <[EMAIL PROTECTED]> wrote:
Okay,
I have a hand-crafted WSDL I'm using to generate Java with WSDL2Java
and I'm using the deployment descriptor generated by WSDL2Java to generate a
server-config.wsdd, which I package in a war and deploy to my tomcat
server.
This has all been working fine and dandy, util today, when I added a
new method that uses (an element and message I had already used
before)...But I'm ending up with this error:
Fault - Bean attribute password is of type
java.lang.String, which is not a simple type
AxisFault
faultCode: {
http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
<http://schemas.xmlsoap.org/soap/envelope/%7DServer.generalException>
faultSubcode:
faultString: Bean attribute password is of type java.lang.String, which is not
a simple type
faultActor:
faultNode:
faultDetail:
{
http://xml.apache.org/axis/}hostname:sludge.marchex.com
<http://xml.apache.org/axis/%7Dhostname:sludge.marchex.com>
The only thing that really makes me scratch my head here is that I
thought xsd:string *was* a simple type? I've got the WSDL and XSDs
generating the code in question attached to this message.
