Hi Mike,

Patch for CXF-157 has been applied, thanks very much.

CXF-158 has been fixed.

Now you can generate code from locator.wsdl and after mannually change LocatorServiceClient.java [1] and [2], you can run server and client successfully.

[1] add jaxws Holder wrapper for port.registerPeerManager, the code should be

port.registerPeerManager(new org.apache.cxf.ws.addressing.EndpointReferenceType(), new Holder<org.apache.cxf.ws.addressing.EndpointReferenceType>(),
                                 new Holder<java.lang.String>());

This is a bug for wsdl2java tool when SEI has Holder parameter

http://issues.apache.org/jira/browse/CXF-172 track this issue

[2] change SERVICE_NAME to
private static final QName SERVICE_NAME = new QName("http://ws.iona.com/2005/11/locator";, "LocatorService");
but not LocatorService_Service

This is also a bug of wsdl2java
http://issues.apache.org/jira/browse/CXF-173  track this issue

And a test will be added later on according to the patch you provided to guarantee anonymous ref is supported in schema.
Thanks very much
Freeman

Ramnarine, Michael wrote:

Dan Diephouse wrote:

Shaw, Richard A wrote:

I've just tried my software with CXF to see if the complex type
issues
I was seeing a few weeks ago are fixed and I think the answer is
sort
of....
I've added a new operation to the hello world sample which has a
complex type in the return. It takes a name and returns the first
and
second name by splitting the input string at the space character.

If my response is defined as per the commented out section below
then
I get an error. If I define it using a named type (the example below
the commented out section) then it is ok.

<element name="splitName">
<complexType>
<sequence>
<element name="name" type="string"/>
</sequence>
</complexType>
</element>
<!-- <element name="splitNameResponse">
<complexType>
<sequence>
<element name="names">
<complexType>
<sequence>
<element name="first" type="string"/>
<element name="second" type="string"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element> -->
<complexType name="names">
<sequence>
<element name="first" type="string"/>
<element name="second" type="string"/>
</sequence>
</complexType>
<element name="splitNameResponse">
<complexType>
<sequence>
<element name="names" type="tns:names"/>
</sequence>
</complexType>
</element>

This is cause by the following rule from WSDLServiceBuilder.class

// If this is an anonymous complex type, mark it as unwrapped.
// We're doing this because things like JAXB don't have support
// for finding classes from anonymous type names.
if (el.getSchemaTypeName() == null && el.getRefName() == null) {
return false;
}

I don't believe this is true because Celtix was quite happy to use
JAXB with anonymous complex types.

If this restriction must apply in CXF then we wont be using it, the
amount of work to change our WSDL definitions to always use types
will
be too prohibitive.

I see what you're saying. This code is actually an artifact from XFire
and arose from times when there was no @Request/ResponseWrapper
annotation. I think we can take this out for now as we always generate
the wrappers with WSDL first code (XFire didn't use too, because it
started before JAX-WS...).

Note: The other issue I had was with arrays of complex types being
returned. This works as long as I name all my types as above.

I got the JAXB people to provide some insight on how to get the
ArrayLists to serialize. I have to finish the client fault handling,
but
as soon as I do that I can make these changes for you...

- Dan

I see this work to handle anonymous complex types was completed
recently.  Thank you!

I submitted two other bugs along similar lines last week:
CXF-157 Runtime error processing anonymous ref in WSDL during ... CXF-158 ClassCastException in
JaxWsServiceFactoryBean.initalizeClassInfo

For CXF-157 I have provided a suggested fix, in the form of a patch, in
the comments section of the bug.  Would someone kindly review this patch
and apply it?

And for CXF-158, I wasn't sure what to do to correct it, but I'm hoping
someone will take a look, and hopefully will see a quick fix for it as
well.
-Mike



--
Freeman Fang
Software Engineer

IONA Asia Pacific Software Development Center
No.2 Floor A Unit Information Center
Zhongguancun Software Park Haidian District,
Beijing, P.R.China

Tel.: +86-10-82825151 -  ex. 551
Fax: +86-10-8282-5210
[EMAIL PROTECTED]
-------------------------------------------------
Making Software Work Together TM



Reply via email to