There's been a lot of traffic over the last few days dealing with exceptions thrown when using JavaBeans as parameters or return values to web services.
I haven't got all the answers (by a lot!) but I've been experiencing some of the same issues. I've come to understand enough about the underlying issues to solve my problems. Here's what I've learned, hope it helps someone else: 1. Using a java class that matches the bean specification is a convenient way for us to represent a SOAP complexType in java. We must remember that SOAP is a language neutral protocol, and we probably don't want to really pass an actual java object. If we do, we're imposing a language requirement at the other end of the transaction. So although we say, for convenience, "I'm passing a bean", we really mean "I'm passing a complex data type, the content of which I will hold in a bean once the SOAP has been parsed." (or "...before constructing a SOAP message", depending on your end of the transaction.) 2. Axis gives you the freedom to choose your working process. You can write WSDL and generate client and server stubs from it; or you can create web service classes and generate your WSDL from them; or you can generate WSDL from deployed services. The WSDL generated from class files or from deployed services may not match if you don't give the Java2WSDL tool the right parameters. In our case, I discovered that generating client stubs from WSDL retrieved from a deployed service was giving us one namespace for the complexType, while generating the WSDL from the source files used to create that service put the complexType in a different namespace. Adding the -p[package]=[namespace] tag to the call to Java2WSDL fixed the problem, when [package] is the package the bean is defined in, and [namespace] is the same namespace as the web service. Hope this insight is useful to someone else. -- Dennis R. Sherman Endeavor Information Systems 847-227-2976 [EMAIL PROTECTED] http://www.endinfosys.com
