JBWS-1260 - What when we cannot unwrap the message parts?

[dlofthouse]

If a user has specified the parameter-style as 'wrapped' but the elements can not be unwrapped because the requirements of the spec have not been met how should we handle this situation?

For JAX-WS the spec says for operations that fail the requirements they should be mapped using non-wrapped style. The JAX-RPC specification does not go into this level of detail.

I have an implementation that can fall back to non-wrapped style if we are unable to unwrap the parts - do we want to do it this way so users can just specify wrapped and we will unwrap where we can or do we want to reject their WSDL if we can not unwrap everything?

[jason.greene]

Sure, we probably should print a warning message though. You can do this by using log.warning, the wstools.sh and bat uses a log4j config that echos to the screen

[dlofthouse]

Thinking about this further some refactoring is going to be required so that the generation of the return type and the generation of the parameters happens together as either of these can affect the decision as to if unwrapping should occur. (I can currently fall back to not unwrapping the return type or parameters independently but not both together).

The current fix for JBWS-1260 contains a lot of scenarios that users are currently experiencing problems with that should be working.

I will get JBWS-1260 finished to just include the scenarios that we should be unwrapping and throw an exception for the scenarios that are not supported. I will raise a feature request to cover falling back to not unwrapping if it is not possible to unwrap the message parts.

[dlofthouse]

http://jira.jboss.com/jira/browse/JBWS-1432