We're not using Java2WSDL. We just write the .wsdd file by hand and then deploy it using the AdminClient, and let Axis create the WSDL.
Our .wsdd files look like this:
<deployment xmlns="http://xml.apache.org/axis/wsdd/";
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java";>
<service name="myService" provider="java:MSG">
<parameter name="className" value="myClass"/>
<parameter name="methodName" value="theMethod"/>
</service>
</deployment>
I don't know whether this fits in with your development process at all, but it works for us.
In other circumstances, we've also used the other techniques that have come up in this thread (passing Strings and byte arrays) and both of these worked for us too. Primarily we do this when we've got a sort of chain of services and we don't want the overhead of converting to and from Documents over and over again as the response passes through intermediate services, or when the XML is coming from a static file.
Steve
Barry Lulas wrote:
Steven,
Thanks for the response. So how do you manage the provider, is this a parameter in the Java2WSDL class?
Thanks!
-----Original Message-----
From: Steven Gollery [mailto: Sent: Wednesday, October 30, 2002 12:00 PM
To: [EMAIL PROTECTED]
Subject: Re: XML and web services
Barry,
We've used services that received and returned Documents before. The
.wsdd for this has to set
provider="java:MSG"
instead of java:RPC. Also -- depending on which version of Axis you're
using -- you may find that you have to pass and return an Element[], but
I think that's not the case in 1.0.
The other thing we ran into is that with message-centric deployment,
there are options you don't have. For instance, we couldn't manage to
get the .wsdd to work if we wanted to deploy some of the methods of a
class as operations: we could deploy one method, or all methods.
We also couldn't figure out how to deploy a service where one method was
message-centric and others were RPC. But both these problems might be
just something we couldn't get right.
Hope this helps.
Steven Gollery
[EMAIL PROTECTED]
Barry Lulas wrote:
> I get the following error message when using the Document version:
>
> The class org.w3c.dom.Document does not contain a default constructor,
> which is a requirement for a bean class. The class cannot be
> converted into an xml schema type. An xml schema anyType will be used
> to define this class in the wsdl file.
>
> Any way around this?
>
> -----Original Message-----
> From: James Black [ mailto:jblack@;ieee.org ]
> Sent: Wednesday, October 30, 2002 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XML and web services
>
>
> Barry Lulas wrote:
>
> > I'm just trying to find the best way to describe the datatype that
> > holds the XML documents.
> >
> > For example, my java interface for the web service may look like this:
> >
> > public interface IMyInterface
> > {
> > public String executeQuery(String query);
> > }
>
> This will allow portability, and works, but you may have problems if
> the XML is not well-formed.
>
> > OR
> >
> > public interface IMyInterface
> > {
> > public Document executeQuery(Document query);
> > }
>
> Never tried this, don't know if there is any portability issues
> involved.
>
> > OR
> >
> > public interface IMyInterface
> > {
> > public byte [] executeQuery(byte [] query);
> > }
>
> There is a penalty paid in creating the byte array, but it is portable
> and doesn't create problems if there is a problem with the XML. The file
> may also be larger due to the base64 encoding, though you could have the
> web service same both the string and byte array to a file and see what
> the size difference is.
>
> Your best bet is to try each method, call the client 10-100 times, and
> time it, see if the penalty paid is too high.
>
