cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <>
Subject Several RFSB/JAXB issues
Date Sun, 25 Nov 2007 23:57:31 GMT
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.

    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. ( in the
javascript project). The following is not WS-I complaint, but what the

    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}return part element name
{uri:org.apache.cxf.javascript.fortest}return references element

View raw message