Page History

...

Simple Pitfall: Unreliable Parameter Names

The following pitfall exists, in fact, for both Simple and JAX-WS, but it is much easier to avoid it with JAX-WS.The typical pattern of a web service is to define a Service Endpoint Interface and then create a class that implements that interface. When you own both ends of the process, you can simply use the SEI in both the server and the client.

The problem has to do with a quirk of Java reflection. If a program uses Java reflection to examine a concrete method of a class, the Java Language Specification requires the system to data available may provide the parameter names from the source. The behavior of current Java compilers depends on whether you ask them to provide debug symbols. However, if a program uses reflection to look at an abstract method, the specification does not require current Java compilers never provide the parameter names.

This leads to If there are no names, Simple creates ugly parameters named arg0, arg1, ... Further, if you forget to specify the SEI when creating a service, and only provide the SEB, Simple will see your concrete methods and assign actual parameter names (if you have debug symbols). If you client uses the SEI, they won't communicate. If you change your mind about debug symbols, you will change the contract.

Thus, while JAX-WS @WebParam annotations may seem noisy and inconvenient, they are, in fact, ensuring that your service has a consistent contract.

If you choose to use the Simple front end, you will need to use parameter elements in a .aegis.xml file to specify the parameter give useful names, or be sure to provide the SEI to the ServerFactoryBean.

...