How can I make a WebMethod parameter required

Question

We use the "start from Java" approach to creating JAX-WS 2.0 web services using the Metro 1.5 stack. When we point a standard tool like SoapUI at one of our web services it indicates that parameters to WebMethods are optional. The generated xsd shows minOccurs=0.

I need a way to make WebMethod parameters required (maybe minOccurs=1 in the xsd) in the "start from Java" approach. I would think there is a Java annotation for this, but I haven't been able to find one. The XmlElement annotation has required attribute, but XmlElement cannot be applied to WebMethod parameters.

Is there a way to make my WebMethod parameters required, short of manually editing the xsd and setting minOccurs to 1?

Answer 1

I've verified that Metro 2.0 does allow you to set @XmlElement(required=true) on a parameter. The generated xsd does not have minOccurs=0. It leaves minOccurs out of the generated xsd so it assumes the default value of 1.

You also have to upgrade your JDK by putting the JAX-WS 2.2 webservices-api.jar in the endorsed/ directory.

I posted the same question on the Java forums.

Thanks to jitu for both the answer and pointing out that minOccurs defaults to 1 so leaving it out of the .xsd has the desired effect.

When @XmlElement(required=true) is set on the parameter SoapUI no longer indicates that the parameter as optional.

Answer 2

Here is another discussion of this same question. According to the response Metro 2.0 supports putting @XmlElement on a method parameter which should solve my problem.

http://forums.java.net/jive/thread.jspa?messageID=385565&#385565

Metro 2.0 was released on Dec. 10, 2009 so it is no longer in EA. I'll give it a try and see if it works.

Answer 3

The generated xsd shows minOccurs=0.

This is per specification: any non-primitives are optional, only primitives are required.

I need a way to make WebMethod parameters required (maybe minOccurs=1 in the xsd) in the "start from Java" approach.

This is not possible, unless you use primitives as previously mentioned.

And actually, this is one of the reasons why Java-first sucks (yeah, developers like it but it just does not work): its fragile, the contract may change(!), its doesn't give you all the control you need, it doesn't fit well with WS-Security, etc. So, indeed, contract-first is not pleasant, but at least, it works.