>>>> If you find a good all-in-one checking tool, please let me know.
You can try the Eclipse WTP project. It has a WSDL/XML Schema editor/validator which seems to work well and doesn't choke on WSDL/XSD imports. http://www.eclipse.org/webtools/ - Junaid Dies Koper <[EMAIL PROTECTED] com> To [email protected] 03/02/2006 07:53 cc PM Subject Re: Fwd: WSDD2Java + Admin util for Please respond to deployment = Undescribably strange [EMAIL PROTECTED] error... he.org 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.
