Re: Migrating to Axis 2
Unfortunately, that is unsatisfactory for migration.I wonder what is stopping there from being wrapping/unwrapping for the wrapped convention.- ScottOn 5/22/06, Anne Thomas Manes [EMAIL PROTECTED] wrote: No -- you just have to use a bean to wrap your parameters. AnneOn 5/20/06, Scott McCoy [EMAIL PROTECTED] wrote: I see, so I'm basically married to axis 1.3 for the time being. - ScottOn 5/20/06, Anne Thomas Manes [EMAIL PROTECTED] wrote:Axis 2 does not yet support automatic unwrapping of wrapped doc/literal ... On 5/20/06, Scott McCoy [EMAIL PROTECTED] wrote: Okay, attached is a WSDL that worked fine for generating very simple to use wrapped document/literal services with WSDL2Java. Now, the code WSDL2Java generates is as though the wrapped document/literal convention is broken. It accepts a Request bean for each argument, and expects a Response bean in return.What the heck? Thanks, Scott S. McCoy -To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migrating to Axis 2
Okay, attached is a WSDL that worked fine for generating very simple to use wrapped document/literal services with WSDL2Java.Now, the code WSDL2Java generates is as though the wrapped document/literal convention is broken. It accepts a Request bean for each argument, and expects a Response bean in return.What the heck? Thanks, Scott S. McCoy ?xml version=1.0 encoding=UTF-8? !-- $Id: account.wsdl,v 1.2 2006/04/26 23:34:09 smccoy Exp $ -- !-- This WSDL is for generation only. It is not WS-I compliant, and actually in some spots might even been poorly formed WSDL. This however makes it easier to read, maintain, reduces duplication, and doesn't matter: The WSDL here is used only for code and further markup generation. A WS-I Compliant WSDL should then be generated from the code generated from this WSDL, by Axis, automatically. -- wsdl:definitions name=urn:Account targetNamespace=http://plapi.enhance.com/service/account; xmlns:tns=http://plapi.enhance.com/service/account; xmlns:typens=http://plapi.enhance.com/service/account; xmlns:authns=http://plapi.enhance.com/credentials; 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 xsd:schema targetNamespace=http://plapi.enhance.com/service/account; xsd:include schemaLocation=account.xsd/ /xsd:schema /wsdl:types wsdl:message name=createAccountRequest wsdl:part name=createAccount element=tns:createAccountRequest/ /wsdl:message wsdl:message name=updateAccountRequest wsdl:part name=updateAccount element=tns:updateAccountRequest/ /wsdl:message wsdl:message name=fetchAccountRequest wsdl:part name=fetchAccount element=tns:fetchAccountRequest/ /wsdl:message wsdl:message name=cancelAccountRequest wsdl:part name=cancelAccount element=tns:cancelAccountRequest/ /wsdl:message wsdl:message name=listAccountsRequest wsdl:part name=listAccounts element=tns:listAccountsRequest/ /wsdl:message wsdl:message name=createUserRequest wsdl:part name=createUser element=tns:createUserRequest/ /wsdl:message wsdl:message name=updateUserRequest wsdl:part name=updateUser element=tns:updateUserRequest/ /wsdl:message wsdl:message name=grantAccessRequest wsdl:part name=grantAccess element=tns:grantAccessRequest/ /wsdl:message wsdl:message name=revokeAccessRequest wsdl:part name=revokeAccess element=tns:revokeAccessRequest/ /wsdl:message wsdl:message name=addFundsRequest wsdl:part name=addFunds element=tns:addFundsRequest/ /wsdl:message wsdl:message name=addCreditCardRequest wsdl:part name=addCreditCard element=tns:addCreditCardRequest/ /wsdl:message !-- we need to return a different message than we accept -- wsdl:message name=createAccountResponse wsdl:part name=response element=tns:createAccountResponse/ /wsdl:message wsdl:message name=updateAccountResponse wsdl:part name=response element=tns:updateAccountResponse/ /wsdl:message wsdl:message name=fetchAccountResponse wsdl:part name=response element=tns:fetchAccountResponse/ /wsdl:message wsdl:message name=cancelAccountResponse wsdl:part name=response element=tns:cancelAccountResponse/ /wsdl:message wsdl:message name=listAccountsResponse wsdl:part name=response element=tns:listAccountsResponse/ /wsdl:message wsdl:message name=createUserResponse wsdl:part name=response element=tns:createUserResponse/ /wsdl:message wsdl:message name=updateUserResponse wsdl:part name=response element=tns:updateUserResponse/ /wsdl:message wsdl:message name=grantAccessResponse wsdl:part name=response element=tns:grantAccessResponse/ /wsdl:message wsdl:message name=revokeAccessResponse wsdl:part name=response element=tns:revokeAccessResponse/ /wsdl:message wsdl:message name=addFundsResponse wsdl:part name=response element=tns:addFundsResponse/ /wsdl:message wsdl:message name=addCreditCardResponse wsdl:part name=response element=tns:addCreditCardResponse/ /wsdl:message wsdl:portType name=AccountService wsdl:operation name=createAccount wsdl:input message=tns:createAccountRequest/ wsdl:output message=tns:createAccountResponse/ /wsdl:operation wsdl:operation name=updateAccount wsdl:input message=tns:updateAccountRequest/ wsdl:output message=tns:updateAccountResponse/ /wsdl:operation wsdl:operation name=fetchAccount wsdl:input message=tns:fetchAccountRequest/ wsdl:output message=tns:fetchAccountResponse/ /wsdl:operation
Re: Question on how to generate faults
In Axis 1, use org.apache.axis.AxisFault.If you just want to wrap an exception, the easiest way is to:catch (Exception exception) { throw AxisFault.makeFault(exception);}Cheers, Scott S. McCoy
On 5/19/06, Venkat Gyambavantha [EMAIL PROTECTED] wrote:
Hi,
I used wsdl2java to generate server
skeleton code. One of my operation can generate fault. The code generated by
wsdl2java has a method that throws the faultmessage (subclass of
RemoteException). How to throw this exception?
Thanks
Re: Migrating to Axis 2
I see, so I'm basically married to axis 1.3 for the time being.- ScottOn 5/20/06, Anne Thomas Manes [EMAIL PROTECTED] wrote:Axis 2 does not yet support automatic unwrapping of wrapped doc/literal ... On 5/20/06, Scott McCoy [EMAIL PROTECTED] wrote: Okay, attached is a WSDL that worked fine for generating very simple to use wrapped document/literal services with WSDL2Java. Now, the code WSDL2Java generates is as though the wrapped document/literal convention is broken. It accepts a Request bean for each argument, and expects a Response bean in return.What the heck? Thanks, Scott S. McCoy -To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WS-I Compliance, SOAP Headers, and Wrapped document/literal
I'm really struggling here, after writing all of my service implementations using approaches discussed in previous threads in this list, I found I was not actually WS-I Compliant as my services were reliant upon the SOAPAction header, which the WS-I
1.1 Profile says I must not do. So, I tried moving to a real document/wrapped convention, where I have a different document level element for each operation. This has effectively broken my handling of my SOAP header, however, and when I do include a SOAP Header explicitly in each message, it breaks the unwrapping of my document element and no longer do I get the method signature I desire.
I am of course using WSDL2JavaWhat I want to get is, for the example I have attached (unfortunately my implementation is a *lot* bigger than this and encompases many operations):public Account createAccount (Credentials credentials, Account account) {
}What I get instead:public Account createAccount (Account account) {}*OR*public Account createAccount (CreateAccount createAccount, Credentials credentials) {}--- Am I forced to do the unwrapping myself or live without actually having my soap header passed? How in the heck do I do this?
Thanks, Scott S. McCoy
?xml version=1.0 encoding=UTF-8?
!-- $Id$ --
!--
This WSDL is for generation only. It is not WS-I compliant, and actually
in some spots might even been poorly formed WSDL. This however makes it
easier to read, maintain, reduces duplication, and doesn't matter: The
WSDL here is used only for code and further markup generation. A WS-I
Compliant WSDL should then be generated from the code generated from this
WSDL, by Axis, automatically.
--
wsdl:definitions name=urn:Account
targetNamespace=http://plapi.enhance.com/service/account;
xmlns:tns=http://plapi.enhance.com/service/account;
xmlns:typens=http://plapi.enhance.com/service/account;
xmlns:authns=http://plapi.enhance.com/credentials;
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
xsd:schema targetNamespace=http://plapi.enhance.com/service/account;
xsd:include schemaLocation=account.xsd/
xsd:import namespace=http://plapi.enhance.com/credentials;
schemaLocation=credentials.xsd/
/xsd:schema
/wsdl:types
!--
wsdl:import namespace=http://plapi.enhance.com/service/account;
location=account.xsd/
wsdl:import namespace=http://plapi.enhance.com/credentials;
location=credentials.xsd/ --
wsdl:message name=Credentials
wsdl:part name=credentials element=authns:credentials/
/wsdl:message
wsdl:message name=createAccountRequest
wsdl:part name=createAccount element=tns:createAccount/
/wsdl:message
wsdl:message name=createAccountResponse
wsdl:part name=createAccountResponse element=tns:account/
/wsdl:message
wsdl:portType name=AccountService
wsdl:operation name=createAccount
wsdl:input message=tns:createAccountRequest/
wsdl:output message=tns:createAccountResponse/
/wsdl:operation
/wsdl:portType
wsdl:binding name=AccountSOAPBinding type=tns:AccountService
soap:binding style=wrapped
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=createAccount
soap:operation soapAction=/
wsdl:input name=createAccountRequest
soap:header use=literal part=credentials message=tns:Credentials/
soap:body use=literal parts=createAccount/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=AccountWebService
wsdl:port name=AccountPort binding=tns:AccountSOAPBinding
soap:address
location=http://localhost:8080/axis/services/Account/
/wsdl:port
/wsdl:service
/wsdl:definitions
account.xsd
Description: Binary data
credentials.xsd
Description: Binary data
Fwd: WSDD2Java + Admin util for deployment = Undescribably strange error...
-- Forwarded message --From: Scott McCoy [EMAIL PROTECTED]Date: Mar 2, 2006 11:33 AMSubject: 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
Re: Fwd: WSDD2Java + Admin util for deployment = Undescribably strange error...
Well I now know for sure that the XSD problems aren't the source, still, with the XSD problems fixed, the code I'm ending up with is still no good.Basically, the dilemma I am facing is that if I use the wrapped document/literal convention, it only works if I don't use SOAP Headers. If I do use SOAP Headers, I end up requiring an object named after my method to hold what would be the method arguments if I wasn't using the wrapped convention. If I don't use this wrapper item, and I just include my arguments as the body parts, then I end up with problems routing my requests (I would be relying on the SOAPAction method anyway, and that would be problematic for WS-I compliance). So how do I get the wrapping magic *and* explicit headers? It's flabbergasting how difficult that seems to be.On 3/2/06, Dies Koper [EMAIL PROTECTED] wrote: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 itis also possible that Axis is choking on them and generates incorrect files.#The first problem I noticed was that you put attributes before sequence in complexTypes.Why don't you google for a WSDL and an XML validator and sort them outfirst?On the WS-I web site there is also a Java-based tool to check whetheryour 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, butnever got it to check imported WSDL/XSD files.If you find a good all-in-one checking tool, please let me know. Regards,DiesScott 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:AccounttargetNamespace= http://plm.marchex.com/service/accountxmlns:tns= http://plm.marchex.com/service/account xmlns:typens= http://plm.marchex.com/service/accountxmlns:authns= http://plm.marchex.com/credentials !-- wrong version of XML Schemaxmlns:xsd=http://www.w3.org/1999/XMLSchema --xmlns:xsd= http://www.w3.org/2001/XMLSchemaxmlns: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/accountlocation=account.xsd/ wsdl:import namespace= http://plm.marchex.com/credentialslocation=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 awrapper element that has the same name as the operation. If you prefer to not use the wrapped convention, you still must define aunique input message for operation becuase the input element foreach 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
WSDL2Java overwriting implementation classes!
Hello, I previously was mapping the WSDL2Java classes to a local namespace for our project. We have determined using the default generated java namespaces for the generated code, and using our internal namespace for the implementation, would be the best course of action. However, when I changed our build and generation process to reflect this suggestion, WSDL2Java started overwriting my implementation class!!-- This works as anticipated -- target name=generate-service java classname=org.apache.axis.wsdl.WSDL2Java fork=true failonerror=true classpath refid=base.classpath/ arg value=--server-side/ arg value=--output/ arg value=src/java/ arg value=--verbose/ arg value=--wrapArrays/ arg value=-Nhttp://plm.marchex.com/credentials=tufte.model.service/ arg value=-Nhttp://plm.marchex.com/service/account=tufte.model.service.account/ arg value=--implementationClassName/ arg value=tufte.model.service.account.ServiceHandler/ arg value=src/xml/account.wsdl/ /java /target!-- This overwrites tufte.model.service.account.ServiceHandler each time! -- target name=generate-plm java classname= org.apache.axis.wsdl.WSDL2Java fork=true failonerror=true classpath refid=base.classpath/ arg value=--server-side/ arg value=--output/ arg value=src/java/ arg value=--verbose/ arg value=--wrapArrays/ arg value=--implementationClassName/ arg value=tufte.model.service.account.ServiceHandler/ arg value=src/xml/account.wsdl/ /java /targetIf anybody has an idea as to why this is happening it would be much appreciated.
Re: WSDL2Java overwriting implementation classes!
After further review, this appears to be a bug between org.apache.axis.wsdl.toJava.JavaBindingWriter and org.apache.axis.wsdl.toJava.Utils (in Axis 1.3). Can someone verify this?Thanks,Scott S. McCoy On 3/1/06, Scott McCoy [EMAIL PROTECTED] wrote: Hello, I previously was mapping the WSDL2Java classes to a local namespace for our project. We have determined using the default generated java namespaces for the generated code, and using our internal namespace for the implementation, would be the best course of action. However, when I changed our build and generation process to reflect this suggestion, WSDL2Java started overwriting my implementation class!!-- This works as anticipated -- target name=generate-service java classname=org.apache.axis.wsdl.WSDL2Java fork=true failonerror=true classpath refid=base.classpath/ arg value=--server-side/ arg value=--output/ arg value=src/java/ arg value=--verbose/ arg value=--wrapArrays/ arg value=-Nhttp://plm.marchex.com/credentials=tufte.model.service/ arg value=-Nhttp://plm.marchex.com/service/account=tufte.model.service.account/ arg value=--implementationClassName/ arg value=tufte.model.service.account.ServiceHandler/ arg value=src/xml/account.wsdl/ /java /target!-- This overwrites tufte.model.service.account.ServiceHandler each time! -- target name=generate-plm java classname= org.apache.axis.wsdl.WSDL2Java fork=true failonerror=true classpath refid=base.classpath/ arg value=--server-side/ arg value=--output/ arg value=src/java/ arg value=--verbose/ arg value=--wrapArrays/ arg value=--implementationClassName/ arg value=tufte.model.service.account.ServiceHandler/ arg value=src/xml/account.wsdl/ /java /targetIf anybody has an idea as to why this is happening it would be much appreciated.
Re: WSDD2Java + Admin util for deployment = Undescribably strange error...
You know, when I tried to make some of these changes, I ran into some trouble. For instance, if I define the soap header and body in different messages, my generated port type interface no longer contains the credentials object in the method signature. Any idea what I'm missing?On 2/22/06, Scott McCoy [EMAIL PROTECTED] wrote: Thanks for your input, although this does generate working code and my actual problem, was that in xsd. But before I complete this project, I do have the requirement of ensuring WS-I compliance, and I think this will help me move in that direction. Thanks,Scott S. McCoyOn 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
Re: WSDD2Java + Admin util for deployment = Undescribably strange error...
I have also noticed that the WSDL generated by the code generated by *my* WSDL seems to mostly conform to your suggestions.Thanks, - ScottOn 2/23/06, Scott McCoy [EMAIL PROTECTED] wrote:You know, when I tried to make some of these changes, I ran into some trouble. For instance, if I define the soap header and body in different messages, my generated port type interface no longer contains the credentials object in the method signature. Any idea what I'm missing?On 2/22/06, Scott McCoy [EMAIL PROTECTED] wrote: Thanks for your input, although this does generate working code and my actual problem, was that in xsd. But before I complete this project, I do have the requirement of ensuring WS-I compliance, and I think this will help me move in that direction. Thanks,Scott S. McCoyOn 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
WSDD2Java + Admin util for deployment = Undescribably strange error...
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 typeAxisFault faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.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
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. Thanks,
Scott S. McCoy
?xml version=1.0 encoding=UTF-8?
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;
xmlns:xsd=http://www.w3.org/1999/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
!--
wsdl:types
xsd:schema targetNamespace=http://plm.marchex.com/services/account;
xmlns:xsd=http://www.w3.org/1999/XMLSchema;
xsd:include schemaLocation=account.xsd/
/xsd:schema
/wsdl:types
--
wsdl:import namespace=http://plm.marchex.com/service/account;
location=account.xsd/
wsdl:import namespace=http://plm.marchex.com/credentials;
location=credentials.xsd/
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
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
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
soap:binding style=wrapped
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:header use=literal part=credentials/
soap:body use=literal part=account/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
wsdl:operation name=updateAccount
soap:operation soapAction=createAccount/
wsdl:input
soap:header use=literal part=credentials/
soap:body use=literal part=account/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
wsdl:operation name=listAccounts
soap:operation soapAction=listAccounts/
wsdl:input
soap:header use=literal/
Re: WSDD2Java + Admin util for deployment = Undescribably strange error...
=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,AnneOn 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 typeAxisFault faultCode: {
http://schemas.xmlsoap.org/soap/envelope/}Server.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
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. Thanks,
Scott S. McCoy
WS-I Compliant messages.
Hello, I am trying to build a mechanism for which authentication takes place in the header. I was able to easily write a lower-level component I can use in the requestFlow/ of my WSDD, the only problem exists in that I need a WSDL that can easily be used to generate a client interface. What are a few solutions for this? I know I can specify my own WSDL through my WSDD, but I am also using WSDL2Java and I don't really want to specify a WSDL other than the one I am using for code generation. I've found a few threads about this, and I used one of them to specify my mechanism for including my header in RPC-style arguments...this allowed me to build a service that accepted two arguments, one for my main body element one for my header element - But I found that in my code when it was actually running, both parts of the message came through in the body. It doesn't matter to me if the authentication is specified through the request flow, or not, but it is part of my specification that it must belong to the header, and I need to have a WS-I compliant WSDL, and it needs to properly match my web service so clients can easily be built. My message needs to look something like:Envelope Header credentials username=... password=../ /Header Body createAccount account name=.. daily-cap=.. auto-renew=../ /createAccount /Body/Element
Re: Passing information between requestFlow handlers
Store it in the MessageContext.MessageContext context = MessageContext.getCurrentContext();context.setProperty(..., object);- Scott S. McCoyOn 2/15/06, Scott McCoy [EMAIL PROTECTED] wrote: I am using Axis 1.3, I am having some trouble passing information between the requestFlow handler and the operation handler of my webservice. I am generating most of my code using WSDL2Java, and then providing a modified version of the generated WSDD to insert a requestFlow handler that peers into my SOAP Header and looks for an element representing the credentials. If this fails, I throw an AxisFault to stop the request and generate a SOAP Fault response. The problem I am having is that in my implementation of my operations, I need an object to integrate with our local utility classes for performing the functions that are needed. One of these that I need is an object by the name of CustomerInfo. This object, is extractable from the other model layer object I used to verify the credentials before allowing the request to continue, but my problem is this: How do I pass data between the two handlers? Thanks, Scott S. McCoy
Re: BSFProvider, anyone?
I saw an IBM article about something similar with Rhino and Axis 1.2, it was geared for E4X, but I once rewrote it to use DOM instead at one point. I don't have the code on this workstation, but I'll dig around my box at home tonight and see if I can post it. You can fetch the code yourself, and rework it with Rhino, but it requires some fairly indepth Rhino knowledge:http://www-128.ibm.com/developerworks/webservices/library/ws-ajax1/ - Scott S. McCoyOn 2/14/06, Davanum Srinivas [EMAIL PROTECTED] wrote: You are better off trying the Rhino sample in Axis2.http://marc.theaimsgroup.com/?l=axis-devm=113459846523498w=2 thanks,dimsOn 2/14/06, Ulf Dittmer [EMAIL PROTECTED] wrote: Hello everyone- I'm trying to get the BSFProvider to work, and am having a hard time. Essentially, Axis doesn't return any response (well, a 202 response with an empty body) according to TCPMon. No error messages anywhere - the call just seems to vanish somewhere in Axis. The only example of using the BSFProvider I found anywhere was a (quite old) calculator.wsdd file, but unfortunately without a client that shows how to construct a call to it. I tried various BSF and _javascript_ versions (of which I know that they work together in general), but no luck. Any help on what to do or where to look for more information would be most welcome. (I'm using Axis 1.2.1 , in case that matters.) Many thanks in advance. Cheers, Ulf--Davanum Srinivas : http://wso2.com/blogs/
Wrapped document/literal services giving me a Holder argument in my binding implementation?
The attached WSDL and XSD are giving me this method signature.public class AccountSOAPBindingImpl implements tufte.model.service.account.Account{ public void createAccount(tufte.model.service.account.holders.AccountHolder
account) throws java.rmi.RemoteException { } public void updateAccount(tufte.model.service.account.holders.AccountHolder account) throws java.rmi.RemoteException { }}I'm expecting:
public void updateAccount(tufte.model.service.account.Account account) throws java.rmi.RemoteException { }Not this.Thanks!Scott S. McCoy
?xml version=1.0 encoding=UTF-8?
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:xsd=http://www.w3.org/1999/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
!--
wsdl:types
xsd:schema targetNamespace=http://plm.marchex.com/services/account;
xmlns:xsd=http://www.w3.org/1999/XMLSchema;
xsd:include schemaLocation=account.xsd/
/xsd:schema
/wsdl:types
--
wsdl:import namespace=http://plm.marchex.com/service/account;
location=account.xsd/
wsdl:message name=AccountDetails
wsdl:part name=account element=tns:account/
/wsdl:message
wsdl:portType name=Account
wsdl:operation name=createAccount
wsdl:input message=tns:AccountDetails/
wsdl:output message=tns:AccountDetails/
/wsdl:operation
wsdl:operation name=updateAccount
wsdl:input message=tns:AccountDetails/
wsdl:output message=tns:AccountDetails/
/wsdl:operation
/wsdl:portType
wsdl:binding name=AccountSOAPBinding type=tns:Account
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=createAccount
soap:operation soapAction=createAccount/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
wsdl:operation name=updateAccount
soap:operation soapAction=createAccount/
wsdl:input
!--soap:body use=encoded
namespace=http://plm.marchex.com/service/account;
encodingStyle=http://schemas.xmlsoap.org/soap/encoding//
--
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=AccountService
!--wsdl:requestFlow No such thing exists, this is just to remind me to
use a custom deploy.wsdd
wsdl:handler
type=java:tufte.model.service.handlers.AuthenHandler/
/wsdl:requestFlow --
wsdl:port name=Account binding=tns:AccountSOAPBinding
soap:address
location=http://localhost:8080/axis/services/Account/
/wsdl:port
/wsdl:service
/wsdl:definitions
account.xsd
Description: Binary data
Re: Wrapped document/literal services giving me a Holder argument in my binding implementation?
I see why, WSDL2Java will not generate a 'wrapped' style service if my complexType has attributes.Does anyone know *why* that is? What is the difference between an attribute and an element that only may have a single occurance?
On 2/14/06, Scott McCoy [EMAIL PROTECTED] wrote:
The attached WSDL and XSD are giving me this method signature.public class AccountSOAPBindingImpl implements tufte.model.service.account.Account{ public void createAccount(tufte.model.service.account.holders.AccountHolder
account) throws java.rmi.RemoteException { } public void updateAccount(tufte.model.service.account.holders.AccountHolder account) throws java.rmi.RemoteException { }}I'm expecting:
public void updateAccount(tufte.model.service.account.Account account) throws java.rmi.RemoteException { }Not this.Thanks!Scott S. McCoy
Re: Wrapped document/literal services giving me a Holder argument in my binding implementation?
Thanks Dies, That totally solved my problem. I have another problem though, after your suggested changes (and before, for that matter) AccountSOAPBindingImpl becomes a class that implements the Account class generated.
The obvious problem with that, is that you cannot implement a class in Java, only an interface. Any idea what I've still got screwed up? Thanks, Scott S. McCoy
On 2/14/06, Dies Koper [EMAIL PROTECTED] wrote:
Hello Scott,In your wsdl:portType definition, you have the same message for theoperation's input and output. Therefore, the parts' names are the same.So you are telling Axis that you want it to be an IN/OUT parameter and
it should use a Holder class as parameter.If you do not want to use a Holder, you should point the operation'soutput to another message, one with a different part name, in this casereferring to a ComplexType with no elements (void wrapper).
Something like: wsdl:message name=AccountDetails wsdl:part name=account element=tns:account/ /wsdl:message wsdl:message name=empty
wsdl:part name=empty element=tns:emptyElement/ /wsdl:message wsdl:portType name=Account wsdl:operation name=createAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:empty/ /wsdl:operation wsdl:operation name=updateAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:empty/ /wsdl:operation /wsdl:portTypeWith in your types section or XSD something like:
xsd:element name=emptyElement xsd:complexType sequence/ /xsd:complexType /xsd:elementBTW: It is not recommended (WS-I
BP1.0) to use wsdl:import to import XSDfiles. Use the commented way (but with import) instead.Regards,DiesScott McCoy wrote: The attached WSDL and XSD are giving me this method signature.
public class AccountSOAPBindingImpl implements tufte.model.service.account.Accou nt{ public void createAccount( tufte.model.service.account.holders.AccountHolder account) throws
java.rmi.RemoteException { } public void updateAccount( tufte.model.service.account.holders.AccountHolder account) throws java.rmi.RemoteException { }
} I'm expecting: public void updateAccount(tufte.model.service.account.Account account) throws java.rmi.RemoteException { } Not this. Thanks!
Scott S. McCoy ?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=urn:AccounttargetNamespace=http://plm.marchex.com/service/accountxmlns:tns=
http://plm.marchex.com/service/accountxmlns:typens=http://plm.marchex.com/service/account
xmlns:xsd=http://www.w3.org/1999/XMLSchemaxmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ !-- wsdl:types xsd:schema targetNamespace=
http://plm.marchex.com/services/account xmlns:xsd=http://www.w3.org/1999/XMLSchema
xsd:include schemaLocation=account.xsd/ /xsd:schema /wsdl:types -- wsdl:import namespace=
http://plm.marchex.com/service/accountlocation=account.xsd/ wsdl:message name=AccountDetails
wsdl:part name=account element=tns:account/ /wsdl:message wsdl:portType name=Account wsdl:operation name=createAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:AccountDetails/ /wsdl:operation wsdl:operation name=updateAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:AccountDetails/ /wsdl:operation /wsdl:portType
wsdl:binding name=AccountSOAPBinding type=tns:Account soap:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=createAccount soap:operation soapAction=createAccount/ wsdl:input
soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output
/wsdl:operation wsdl:operation name=updateAccount soap:operation soapAction=createAccount/ wsdl:input
!--soap:body use=encodednamespace=http://plm.marchex.com/service/accountencodingStyle=
http://schemas.xmlsoap.org/soap/encoding//-- soap:body use=literal/ /wsdl:input
wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding
wsdl:service name=AccountService !--wsdl:requestFlowNo such thing exists, this is just to remind me to use a custom deploy.wsdd
wsdl:handler type=java:tufte.model.service.handlers.AuthenHandler/ /wsdl:requestFlow -- wsdl:port name=Account binding=tns:AccountSOAPBinding
soap:address location=http://localhost:8080/axis/services/Account/ /wsdl:port
/wsdl:service /wsdl:definitions--Dies KOPER [EMAIL PROTECTED] (changed on 1 July 2005)Fujitsu Ltd - MWPF1(changed from MWPF3 on 21 Nov 2005)
2-15-16, Shin-Yokohama, Kouhoku-ku, Yokohama, 222-0033, JapanTel. +81(45)-475-5605(internal 7181-4217)
Re: Wrapped document/literal services giving me a Holder argument in my binding implementation?
Actually I seem to have solved that too, I cannot have a port type and an element of the same name, otherwise one overwrites the other apparently.Thanks, Scott S. McCoy
On 2/14/06, Scott McCoy [EMAIL PROTECTED] wrote:
Thanks Dies, That totally solved my problem. I have another problem though, after your suggested changes (and before, for that matter) AccountSOAPBindingImpl becomes a class that implements the Account class generated.
The obvious problem with that, is that you cannot implement a class in Java, only an interface. Any idea what I've still got screwed up? Thanks, Scott S. McCoy
On 2/14/06, Dies Koper [EMAIL PROTECTED] wrote:
Hello Scott,In your wsdl:portType definition, you have the same message for theoperation's input and output. Therefore, the parts' names are the same.So you are telling Axis that you want it to be an IN/OUT parameter and
it should use a Holder class as parameter.If you do not want to use a Holder, you should point the operation'soutput to another message, one with a different part name, in this casereferring to a ComplexType with no elements (void wrapper).
Something like: wsdl:message name=AccountDetails wsdl:part name=account element=tns:account/ /wsdl:message wsdl:message name=empty
wsdl:part name=empty element=tns:emptyElement/ /wsdl:message wsdl:portType name=Account wsdl:operation name=createAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:empty/ /wsdl:operation wsdl:operation name=updateAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:empty/ /wsdl:operation /wsdl:portTypeWith in your types section or XSD something like:
xsd:element name=emptyElement xsd:complexType sequence/ /xsd:complexType /xsd:elementBTW: It is not recommended (WS-I
BP1.0) to use wsdl:import to import XSDfiles. Use the commented way (but with import) instead.Regards,DiesScott McCoy wrote: The attached WSDL and XSD are giving me this method signature.
public class AccountSOAPBindingImpl implements tufte.model.service.account.Accou nt{ public void createAccount( tufte.model.service.account.holders.AccountHolder account) throws
java.rmi.RemoteException { } public void updateAccount( tufte.model.service.account.holders.AccountHolder account) throws java.rmi.RemoteException { }
} I'm expecting: public void updateAccount(tufte.model.service.account.Account account) throws java.rmi.RemoteException { } Not this. Thanks!
Scott S. McCoy ?xml version=1.0 encoding=UTF-8?
wsdl:definitions name=urn:AccounttargetNamespace=http://plm.marchex.com/service/account
xmlns:tns=
http://plm.marchex.com/service/accountxmlns:typens=
http://plm.marchex.com/service/account
xmlns:xsd=http://www.w3.org/1999/XMLSchemaxmlns:soap=
http://schemas.xmlsoap.org/wsdl/soap/
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ !--
wsdl:types xsd:schema targetNamespace=
http://plm.marchex.com/services/account xmlns:xsd=
http://www.w3.org/1999/XMLSchema
xsd:include schemaLocation=account.xsd/ /xsd:schema /wsdl:types -- wsdl:import namespace=
http://plm.marchex.com/service/accountlocation=account.xsd
/ wsdl:message name=AccountDetails
wsdl:part name=account element=tns:account/ /wsdl:message wsdl:portType name=Account wsdl:operation name=createAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:AccountDetails/ /wsdl:operation wsdl:operation name=updateAccount
wsdl:input message=tns:AccountDetails/ wsdl:output message=tns:AccountDetails/ /wsdl:operation /wsdl:portType
wsdl:binding name=AccountSOAPBinding type=tns:Account soap:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=createAccount soap:operation soapAction=createAccount/ wsdl:input
soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output
/wsdl:operation wsdl:operation name=updateAccount soap:operation soapAction=createAccount/ wsdl:input
!--soap:body use=encodednamespace=
http://plm.marchex.com/service/accountencodingStyle=
http://schemas.xmlsoap.org/soap/encoding//--
soap:body use=literal/ /wsdl:input
wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding
wsdl:service name=AccountService !--wsdl:requestFlowNo such thing exists, this is just to remind me to use a custom deploy.wsdd
wsdl:handler type=java:tufte.model.service.handlers.AuthenHandler/ /wsdl:requestFlow -- wsdl:port name=Account binding=tns:AccountSOAPBinding
soap:address location=http://localhost:8080/axis/services/Account
/ /wsdl:port
/wsdl:service /wsdl:definitions--Dies KOPER [EMAIL PROTECTED]
(changed on 1 July 2005)Fujitsu Ltd - MWPF1(changed from MWPF3 on 21 Nov 2005)
2-15-16, Shin-Yokohama, Kouhoku-ku, Yokohama, 222-0033, JapanTel. +81(45)-475-5605(internal 7181-4217)
Re: Arbitrary Authenitcation Types (based on SOAP Headers)
Thanks, I actually found this project last friday, did attempt to convince the specifications author to adhere to these standards, and he refused. I am still missing something from this project, though, and that is how I can *clearly* annotate the requirements of this headers presence in the WSDL. There 'aught to be something to outline that for me, but what, I'm not sure. Thanks, Scott S. McCoyOn 2/13/06, Rodrigo Ruiz [EMAIL PROTECTED] wrote:Hi Scott, take a look at the wss4j project (at http://ws.apache.org/wss4j). It is a security framework that can do whatyou describe, and some more things, like using client certificatesinstead of name/password pairs. It is probably your best option if you are looking for a standard implementation :-)Even if your specification mandates a custom header (in that case Iwould try to convince the author to adhere to the standard :-P), you canget ideas from the code, as it uses handlers. HTH,Rodrigo RuizScott McCoy wrote: That is the client answer, sure. Virtually what I was looking for, but I wanted the server answer.! I want to use wsdl2java to build a service I will deploy with axis, rather than connect to.I am trying to figure out the most pragmatic fasion for building a component, that I could stuff (possibly, in the requestFlow/) that checks the headers, and *stops* the request from getting to the main handler under the instance that my authentication failed. I really wanted to, if possible, use document or wrapped style services, rather than messages style services, also. Thanks! Scott S. McCoy On 2/10/06, * Rave, Mark* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: I don't know if this is what you are asking but it can't hurt to offer it.I used WSDL2Java to generate the stubs and I also had to have authentication information in the SOAP header, this is how I did it but it might not be the best way: SomethingService service = new SomethingServiceLocator(); Something svc = service.getSomethingSOAPPort(); SomethingSoapBindingStub stub = (SomethingSoapBindingStub)svc; SOAPHeaderElement she = new SOAPHeaderElement(namespace, AuthInfo); SOAPElement ut = she.addChildElement(UserToken); SOAPElement un = ut.addChildElement(UserName); un.addTextNode(username); SOAPElement pw = ut.addChildElement(Password); pw.addTextNode(password); stub.setHeader(she); When I make the call something like this is generated: SOAP-ENV:Envelope xmlns:SOAP-ENV= http://schemas.xmlsoap.org/soap/envelope/ xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:m=namespace SOAP-ENV:Header m:AuthInfo m:UserToken m:UserNameusername/m:UserName m:Passwordpassword/m:Password /m:UserToken /m:AuthInfo /SOAP-ENV:Header .. /SOAP-ENV:Envelop Hope this helps. -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]]On Behalf Of Scott McCoy Sent: Friday, February 10, 2006 2:06 PM To: axis-user@ws.apache.org mailto:axis-user@ws.apache.org Subject: Re: Arbitrary Authenitcation Types (based on SOAP Headers) I didn't get a response to this, so I thought I'd re-post it. I just want a handler, before my handler, to get some values from the header and have the ability to stop the request. How does that happen? On 2/8/06, Scott McCoy [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello All, I have a specification that demands I use a SOAP Header element for credential verification, and from a technical perspective it needs to be highly reusable, with a technical requirement that it preceeds and stops processing of the SOAP Body.I've found what seems to be just the ticket, which is simply adding a component via the requestFlow/ element in WSDL or WSDD...But the problem I'm having is that I'm having difficulty finding documentation on doing this. Essentially, I have the following (mock) request envelope: Envelope xmlns=?soap Header authenticate username=... password=.../ /Header Body purchase order accountid=.. cardid=.. amount=../ order accountid=.. cardid=.. amount=../ /purchase /Body /Envelope Nevermind the details of the SOAP Body, handlers for this are easily generatable by WSDL2Java, but how do I deal with the SOAP Header in a respectible and logical fasion (Axis 1.3) ? Thanks, Scott S. McCoy _ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. Espanol - Deutsch - Nederlands - Francais - Italiano - Norsk - Svenska: www.cardinalhealth.com/legal/email http://www.cardinalhealth.com/legal/email No virus found in this incoming message. Checked by AVG Free Edition. Version
Re: Arbitrary Authenitcation Types (based on SOAP Headers)
I didn't get a response to this, so I thought I'd re-post it.I just want a handler, before my handler, to get some values from the header and have the ability to stop the request.How does that happen? On 2/8/06, Scott McCoy [EMAIL PROTECTED] wrote: Hello All, I have a specification that demands I use a SOAP Header element for credential verification, and from a technical perspective it needs to be highly reusable, with a technical requirement that it preceeds and stops processing of the SOAP Body. I've found what seems to be just the ticket, which is simply adding a component via the requestFlow/ element in WSDL or WSDD...But the problem I'm having is that I'm having difficulty finding documentation on doing this. Essentially, I have the following (mock) request envelope:Envelope xmlns=?soap Header authenticate username=... password=.../ /Header Body purchase order accountid=.. cardid=.. amount=../ order accountid=.. cardid=.. amount=../ /purchase /Body/Envelope Nevermind the details of the SOAP Body, handlers for this are easily generatable by WSDL2Java, but how do I deal with the SOAP Header in a respectible and logical fasion (Axis 1.3) ? Thanks, Scott S. McCoy
Re: Arbitrary Authenitcation Types (based on SOAP Headers)
That is the client answer, sure.Virtually what I was looking for, but I wanted the server answer.!I want to use wsdl2java to build a service I will deploy with axis, rather than connect to. I am trying to figure out the most pragmatic fasion for building a component, that I could stuff (possibly, in the requestFlow/) that checks the headers, and *stops* the request from getting to the main handler under the instance that my authentication failed. I really wanted to, if possible, use document or wrapped style services, rather than messages style services, also.Thanks! Scott S. McCoyOn 2/10/06, Rave, Mark [EMAIL PROTECTED] wrote: I don't know if this is what you are asking but it can't hurt to offer it.I used WSDL2Java to generate the stubs and I also had to have authentication information in the SOAP header, this is how I did it but it might not be the best way: SomethingService service = new SomethingServiceLocator();Something svc = service.getSomethingSOAPPort();SomethingSoapBindingStub stub = (SomethingSoapBindingStub)svc;SOAPHeaderElement she = new SOAPHeaderElement(namespace, AuthInfo); SOAPElement ut = she.addChildElement(UserToken);SOAPElement un = ut.addChildElement(UserName);un.addTextNode(username);SOAPElement pw = ut.addChildElement(Password); pw.addTextNode(password);stub.setHeader(she);When I make the call something like this is generated:SOAP-ENV:Envelope xmlns:SOAP-ENV= http://schemas.xmlsoap.org/soap/envelope/ xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:m=namespaceSOAP-ENV:Headerm:AuthInfo m:UserTokenm:UserNameusername/m:UserNamem:Passwordpassword/m:Password/m:UserToken /m:AuthInfo/SOAP-ENV:Header../SOAP-ENV:EnvelopHope this helps.-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott McCoySent: Friday, February 10, 2006 2:06 PMTo: axis-user@ws.apache.orgSubject: Re: Arbitrary Authenitcation Types (based on SOAP Headers) I didn't get a response to this, so I thought I'd re-post it.I just want a handler, before my handler, to get some values from the header and have the ability to stop the request.How does that happen? On 2/8/06, Scott McCoy [EMAIL PROTECTED] wrote:Hello All,I have a specification that demands I use a SOAP Header element for credential verification, and from a technical perspective it needs to be highly reusable, with a technical requirement that it preceeds and stops processing of the SOAP Body.I've found what seems to be just the ticket, which is simply adding a component via the requestFlow/ element in WSDL or WSDD...But the problem I'm having is that I'm having difficulty finding documentation on doing this. Essentially, I have the following (mock) request envelope:Envelope xmlns=?soapHeaderauthenticate username=... password=.../ /HeaderBodypurchaseorder accountid=.. cardid=.. amount=../order accountid=.. cardid=.. amount=../ /purchase/Body/EnvelopeNevermind the details of the SOAP Body, handlers for this are easily generatable by WSDL2Java, but how do I deal with the SOAP Header in a respectible and logical fasion (Axis 1.3) ?Thanks,Scott S. McCoy_This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. Espanol - Deutsch - Nederlands - Francais - Italiano - Norsk - Svenska: www.cardinalhealth.com/legal/email
Arbitrary Authenitcation Types (based on SOAP Headers)
Hello All, I have a specification that demands I use a SOAP Header element for credential verification, and from a technical perspective it needs to be highly reusable, with a technical requirement that it preceeds and stops processing of the SOAP Body. I've found what seems to be just the ticket, which is simply adding a component via the requestFlow/ element in WSDL or WSDD...But the problem I'm having is that I'm having difficulty finding documentation on doing this. Essentially, I have the following (mock) request envelope:Envelope xmlns=?soap Header authenticate username=... password=.../ /Header Body purchase order accountid=.. cardid=.. amount=../ order accountid=.. cardid=.. amount=../ /purchase /Body/Envelope Nevermind the details of the SOAP Body, handlers for this are easily generatable by WSDL2Java, but how do I deal with the SOAP Header in a respectible and logical fasion (Axis 1.3) ? Thanks, Scott S. McCoy
Confused about more advanced WSDD usage
Hello All, I am trying to implement a message-style API (as opposed to the automagical RPC stuff I've seen). I'd like, however, to write my java service handlers in a more traditional fasion rather than accepting document fragments and handling them with a bunch of DOM code. So I was doing some reading about WSDD/WSDL and Schema, and this should be possible. But I'm not quite sure how it works, and the more I read and look at examples the more I spin my wheels.
Basically, I have a document fragment like this: xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/ xsd:attribute name=id type=xsd:integer/
xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items -- xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=purchase type=xsd:float/ xsd:attribute name=cardnumber type=xsd:string/
/xsd:complexType /xsd:element
xsd:element name=balance type=xsd:float/
/xsd:sequence /xsd:complexTypeI would like to both return and accept this.It seems it should be possible, through some magic I don't quite yet understand, to map a service call to it with the following form:
public ? Dunno handler (Date date, int id, int accountid, Item[] lineItems, float balance) {}Also, there should be some way to return this from a webservice handler as well.Can someone clear up how this works, exactly? Simply defining this complexType as mapping to a specific method, as above, and being able to return such a thing.
My next question, is how can I stuff a handler in my request flow that will read the header and determine weither or not the main service handler is allowed to be called? I would like to use this for a custom form of authentication, in which I check the soap envelopes Header before allowing the soap body elements to get mapped to method calls.
Thanks.Scott S. McCoy
Re: Confused about more advanced WSDD usage
This is quite close to what I am after, I want a properly marked up XML Document fragement to be my message.Imagine your example, except with a few attributes :) The:item attr1/attr
attr2/attr/itemapproach to XML I find painful.We already have documents defined, and I am trying to model our services around them.For instance, we have an invoice document, with an xsd of:
xsd:element name=invoice type=invoice/ !-- An invoice is the result of an order -- xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/
xsd:attribute name=id type=xsd:integer/ xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items --
xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded xsd:complexType xsd:attribute name=purchase type=xsd:float/
xsd:attribute name=cardnumber type=xsd:string/ /xsd:complexType /xsd:element !-- An invoice returns an existing balance --
xsd:element name=balance type=xsd:float/ /xsd:sequence /xsd:complexTypeI would like to return this from my webservice call. It will accept a different document type to define the order:
xsd:element name=order type=order/ xsd:complexType name=order xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=cardid type=xsd:integer/ xsd:attribute name=amount type=xsd:float/
/xsd:complexType /xsd:element /xsd:complexTypeI would like to map these, attributes, etc, to service calls in the cleanest fasion possible with the most behind the scenes action from Axis available.
However, your example seems to not agree with wsdl2java so I'm having difficulty seeing how it really works. After the changes made (Which I stumbled upon myself but noticed someone had already posted about) that are required to make it a valid XML document, it seems to still not be a valid WSDL document:
java.io.IOException: Emitter failure. Invalid endpoint address in port addSoapPort in service AddServiceLocator: ... at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java
:242) at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127) at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112) at org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate
(JavaGeneratorFactory.java:421) at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476) at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run
(Parser.java:362) at java.lang.Thread.run(Thread.java:595)On 2/7/06, Anne Thomas Manes [EMAIL PROTECTED]
wrote:I don't understand what you mean. The messaging API (i.e., provider=java:MSG) is a low-level API in which the application programmatically constructs and processes XML messages using DOM. If you don't want to work with DOM, then you shouldn't use the messaging API.
To produce a method like this:public invoice handler (Calendar date, int id, int accountid, Item[] lineItems, float balance) {}you need to use the RPC API (
i.e., provider=java:RPC). The RPC API does automagic mapping of Java objects to XML types. (Note that per the JAX-RPC spec, you should use Calendar instead of Date)Perhaps what you want is to use document style messages as opposed to rpc/encoded? Well -- you still use the RPC API. (Don't you hate these overloaded terms?) The RPC API supports four message styles: rpc/encoded, rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you want wrapped doc/literal. If you are generating the WSDL then specify style=WRAPPED in the WSDD. If you are generating code from WSDL, then you have to follow the wrapped convention in your WSDL. See my blog entry for instructions:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
Anne
On 2/7/06, Scott McCoy [EMAIL PROTECTED] wrote:
Hello All, I am trying to implement a message-style API (as opposed to the automagical RPC stuff I've seen). I'd like, however, to write my java service handlers in a more traditional fasion rather than accepting document fragments and handling them with a bunch of DOM code. So I was doing some reading about WSDD/WSDL and Schema, and this should be possible. But I'm not quite sure how it works, and the more I read and look at examples the more I spin my wheels.
Basically, I have a document fragment like this: xsd:complexType name=invoice xsd:attribute name=date type=xsd:date/ xsd:attribute name=id type=xsd:integer/
xsd:attribute name=accountid type=xsd:integer/ !-- An invoice may have one or more line items -- xsd:sequence xsd:element name=item minOccurs=0 maxOccurs=unbounded
xsd:complexType xsd:attribute name=purchase type=xsd:float/ xsd:attribute name=cardnumber type=xsd:string/
/xsd:complexType /xsd:element
xsd:element name=balance type=xsd:float/
/xsd:sequence /xsd:complexTypeI would like to both return and accept this.It seems it should be possible, through some magic I don't quite yet understand, to map a service call
WSDL2Java NullPointerException (?)
With the attached documents, I attempt to use WSDL2Java to build some empty classes for me, however, I get this error:java.lang.NullPointerException at org.apache.axis.wsdl.symbolTable.SymbolTable.populateServices (SymbolTable.java:3069) at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:745) at org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:543) at org.apache.axis.wsdl.symbolTable.SymbolTable.populate (SymbolTable.java:518) at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:495) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:361) at java.lang.Thread.run (Thread.java:595) ?xml version=1.0 encoding=UTF-8? wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; targetNamespace=http://tufte/services/Account.xsd; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:types=http://tufte/services/Account.xsd; xmlns:tns=http://schemas.xmlsoap.org/wsdl/soap/; xmlns=http://tufte/services/Account.xsd; wsdl:import namespace=http://tufte/services/Account.xsd; location=invoice.xsd/ wsdl:message name=invoice wsdl:part name=parameters element=types:invoice/ /wsdl:message wsdl:message name=purchase wsdl:part name=parameters element=types:order/ /wsdl:message wsdl:portType name=purchasePort wsdl:operation name=purchase wsdl:input message=purchase/ wsdl:output message=invoice/ /wsdl:operation /wsdl:portType wsdl:binding name=AccountOrderBinding type=purchasePort soap:binding style=document transport=http://scheams.xmlsoap.org/soap/http/ wsdl:operation name=purchase soap:operation style=document soapAction=purchase/ wsdl:inputsoap:body use=literal//wsdl:input wsdl:outputsoap:body use=literal//wsdl:output /wsdl:operation /wsdl:binding wsdl:service wsdl:port name=purchasePort binding=AccountOrderBinding soap:address location=http://localhost/axis/services/Account/ /wsdl:port /wsdl:service /wsdl:definitions invoice.xsd Description: Binary data
Service startup/initialization
Hello, I have run into a problem. I need to add some initialization code to my web service, since this is a simple daemon service I'm using org.apache.axis.transport.http.SimpleAxisServer, rather than normal servlet container. The approach I attempted to use to solve this issue was adding static { } blocks to my code, however, these don't get invoked until the first service request is made, and my first service request wont be made until I subscribe to the publisher that will be sending me service requests.
So what's the best course of action here? Thanks, Scott S. McCoy
Re: Calling Axis' getVersion manually
Thanks, In order to get what I was after, I just did netcat -l -p 9000 and java org.apache.axis.Version http://127.0.0.1:9000/axis/services/Version- Scott On 11/21/05, Davanum Srinivas [EMAIL PROTECTED] wrote: try runningjava org.apache.axis.Version-lhttp://scottmc-laptop:8080/axis/services/Version-- dimsOn 11/21/05, Scott McCoy [EMAIL PROTECTED] wrote: Actually I'm not having any luck calling axis services with the SOAP client's I typically use, is there anything different about what Axis may be anticipating? On 11/20/05, Scott McCoy [EMAIL PROTECTED] wrote: I've been trying to custom-craft a provider for axis, and in testing it I determined my test was broken...and in testing my test, I determined there is something about calling Axis services I don't understand, so I'm trying to figure out what I am missing about the transaction with the HTTP server. Below, is my HTTP/SOAP conversation with Axis.At the very fundemental protcol level, what do I have wrong here?Figuring this out could help me figure out whats wrong with my provider :-) POST http://scottmc-laptop:8080/axis/services/Version HTTP/1.1 Content-Length: 152 Content-Type: text/xml; charset=UTF-8 SOAPAction: Version#getVersion ?xml version=1.0 encoding=UTF-8 standalone=no ?Envelope xmlns= http://schemas.xmlsoap.org/soap/envelope/BodygetVersion//Body/Envelope HTTP/1.0 500 Internal server error Set-Cookie: 7 Set-Cookie2: 7 Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv= http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance soapenv:Body soapenv:Fault faultcode xmlns:ns1= http://xml.apache.org/axis/ns1:Server.NoService/faultcode faultstringThe AXIS engine could not find a target service to invoke!targetService is null/faultstring detail ns2:stackTrace xmlns:ns2=http://xml.apache.org/axis/The AXIS engine could not find a target service to invoke!targetService is null at org.apache.axis.server.AxisServer.invoke(AxisServer.java:270) at org.apache.axis.transport.http.SimpleAxisWorker.execute(SimpleAxisWorker.java:428) at org.apache.axis.transport.http.SimpleAxisWorker.run(SimpleAxisWorker.java:155) at org.apache.axis.transport.http.SimpleAxisServer.run(SimpleAxisServer.java:245) at org.apache.axis.transport.http.SimpleAxisServer.start(SimpleAxisServer.java:296) at org.apache.axis.transport.http.SimpleAxisServer.start(SimpleAxisServer.java:304) at org.apache.axis.transport.http.SimpleAxisServer.main(SimpleAxisServer.java:385) /ns2:stackTrace ns3:hostname xmlns:ns3= http://xml.apache.org/axis/scottmc-laptop/ns3:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope --Davanum Srinivas : http://wso2.com/blogs/
Calling Axis' getVersion manually
I've been trying to custom-craft a provider for axis, and in testing it I determined my test was broken...and in testing my test, I determined there is something about calling Axis services I don't understand, so I'm trying to figure out what I am missing about the transaction with the HTTP server. Below, is my HTTP/SOAP conversation with Axis. At the very fundemental protcol level, what do I have wrong here? Figuring this out could help me figure out whats wrong with my provider :-) POST http://scottmc-laptop:8080/axis/services/Version HTTP/1.1 Content-Length: 152 Content-Type: text/xml; charset=UTF-8 SOAPAction: Version#getVersion ?xml version=1.0 encoding=UTF-8 standalone=no ?Envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/BodygetVersion//Body/Envelope HTTP/1.0 500 Internal server error Set-Cookie: 7 Set-Cookie2: 7 Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance soapenv:Body soapenv:Fault faultcode xmlns:ns1=http://xml.apache.org/axis/ns1:Server.NoService/faultcode faultstringThe AXIS engine could not find a target service to invoke! targetService is null/faultstring detail ns2:stackTrace xmlns:ns2=http://xml.apache.org/axis/The AXIS engine could not find a target service to invoke! targetService is null at org.apache.axis.server.AxisServer.invoke(AxisServer.java:270) at org.apache.axis.transport.http.SimpleAxisWorker.execute(SimpleAxisWorker.java:428) at org.apache.axis.transport.http.SimpleAxisWorker.run(SimpleAxisWorker.java:155) at org.apache.axis.transport.http.SimpleAxisServer.run(SimpleAxisServer.java:245) at org.apache.axis.transport.http.SimpleAxisServer.start(SimpleAxisServer.java:296) at org.apache.axis.transport.http.SimpleAxisServer.start(SimpleAxisServer.java:304) at org.apache.axis.transport.http.SimpleAxisServer.main(SimpleAxisServer.java:385) /ns2:stackTrace ns3:hostname xmlns:ns3=http://xml.apache.org/axis/scottmc-laptop/ns3:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope
Re: Calling Axis' getVersion manually
Actually I'm not having any luck calling axis services with the SOAP client's I typically use, is there anything different about what Axis may be anticipating?On 11/20/05, Scott McCoy [EMAIL PROTECTED] wrote: I've been trying to custom-craft a provider for axis, and in testing it I determined my test was broken...and in testing my test, I determined there is something about calling Axis services I don't understand, so I'm trying to figure out what I am missing about the transaction with the HTTP server. Below, is my HTTP/SOAP conversation with Axis. At the very fundemental protcol level, what do I have wrong here? Figuring this out could help me figure out whats wrong with my provider :-) POST http://scottmc-laptop:8080/axis/services/Version HTTP/1.1 Content-Length: 152 Content-Type: text/xml; charset=UTF-8 SOAPAction: Version#getVersion ?xml version=1.0 encoding=UTF-8 standalone=no ?Envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/BodygetVersion//Body/Envelope HTTP/1.0 500 Internal server error Set-Cookie: 7 Set-Cookie2: 7 Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:xsd=http://www.w3.org/2001/XMLSchema xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance soapenv:Body soapenv:Fault faultcode xmlns:ns1=http://xml.apache.org/axis/ns1:Server.NoService/faultcode faultstringThe AXIS engine could not find a target service to invoke! targetService is null/faultstring detail ns2:stackTrace xmlns:ns2=http://xml.apache.org/axis/The AXIS engine could not find a target service to invoke! targetService is null at org.apache.axis.server.AxisServer.invoke(AxisServer.java:270) at org.apache.axis.transport.http.SimpleAxisWorker.execute(SimpleAxisWorker.java:428) at org.apache.axis.transport.http.SimpleAxisWorker.run(SimpleAxisWorker.java:155) at org.apache.axis.transport.http.SimpleAxisServer.run(SimpleAxisServer.java:245) at org.apache.axis.transport.http.SimpleAxisServer.start(SimpleAxisServer.java:296) at org.apache.axis.transport.http.SimpleAxisServer.start(SimpleAxisServer.java:304) at org.apache.axis.transport.http.SimpleAxisServer.main(SimpleAxisServer.java:385) /ns2:stackTrace ns3:hostname xmlns:ns3=http://xml.apache.org/axis/scottmc-laptop/ns3:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope
