Several RFSB/JAXB issues

[Benson Margulies <bi...@basistech.com>]

This is a bit of a best-of album.

1: Auto-Wrappers and Elements in Doc/Lit/Wrapped 

The following produces a wrapper element with two ref elements, each to
the same element, one with maxOccurs turned up. wsdl2java recommends
adding an annotation to clarify. I propose that this case prefer the
WebParam to the XmlRootElement. After all, we've invented this
auto-wrapper business, we should be able to choose what we want. My
proposal is to make the two MessagePartInfo's in this case return false
from isElement, resulting in a using the names from the WebParams.

@WebMethod
    void beanFunction(@WebParam(name = "bean1") TestBean1 bean, 
                      @WebParam(name = "beanArray") TestBean1[] beans);

2: Array confusion in Doc/Lit/Bare

I'd put this in JIRA, but JIRA is down. (SimpleDocLitBare.java in the
javascript project). The following is not WS-I complaint, but what the
heck...

 @WebMethod
    void beanFunction(@WebParam(name = "bean1") TestBean1 bean, 
                      @WebParam(name = "beanArray") TestBean1[] beans);

The result is an inconsistent situation. The MessagePartInfo for
beanArray has element=true, and points directly to the TestBean1 global
element. At the same time, there is a type object in there, which
(correctly) indicates an array type. I could make my validator notice
this by cross-checking the element's type with the part's type.

3: Missing elements

I cleaned up some over-busy checking, and I/we are left with complaints
like the following for the schema off of the service model. I suspect
that these happen when we have simple types.

{uri:org.apache.cxf.javascript.fortest}d part element name
{uri:org.apache.cxf.javascript.fortest}d references element
{uri:org.apache.cxf.javascript.fortest}d

{uri:org.apache.cxf.javascript.fortest}return part element name
{uri:org.apache.cxf.javascript.fortest}return references element
{uri:org.apache.cxf.javascript.fortest}return