Hi,
I think we have two issues here:
1) Generate the WSDL port type from a java interface following the JAX-WS
mapping rules (JSR-181 annotations can be used to customize the WSDL). The
SCA spec chooses JAX-WS to map between remotable java interfaces and WSDLs.
I assume Simon's proposal is for this step.
2) Generate or map the XML Schema for the java parameter types, return type
and exception types. The data can be represented by different databindings
such as JAXB, SDO or XMLBeans. Some of them have metadata for the XML
elements/types such as JAXB annotations and SDO Type/Property. We need to
make sure the generated XSDs are consistent with these information. The
Java2XSD should be pluggable based on the databindings.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, February 10, 2008 12:42 PM
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as
service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the
namespace
Jean-Sebastien Delfino wrote:
Clemens Utschig - Utschig wrote:
Folks,
I have a simple composite as below - which makes use of SDO through SOAP
in the reference
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="/model/common/"
xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
xmlns:types="/model/common/types/"
xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
<component name="FlexEmployeeServiceComponent">
<implementation.java
class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
<reference name="empFlexFieldService"/>
</component>
<reference name="empFlexFieldService"
promote="FlexEmployeeServiceComponent/empFlexFieldService">
<interface.java
interface="model.common.serviceinterface.EmpFlexFieldService"/>
<binding.ws
uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
</reference>
</composite>
that promotes the java interface from the reference as service .. the
interface is annotated as webservice - as below ..
@javax.jws.WebMethod(action="/model/common/createEmployees1",
operationName="createEmployees1")
@javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
localName="createEmployees1")
@javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
localName="createEmployees1Response")
@javax.jws.WebResult(name="result")
DataObject
createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
name="employees1")
DataObject employees1) throws ServiceException;
which implies that the namespace for this element is
"/model/common/types/"
however - Axis2, takes the targetNamespace - and hence tries to send out
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
<soapenv:Body>
<_ns_:getEmployees1 xmlns:_ns_="/model/common/">
<empno xmlns="/model/common/">1</empno>
</_ns_:getEmployees1>
</soapenv:Body>
</soapenv:Envelope>
instead of
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
<soap:Body xmlns:ns1="/model/common/types/">
<ns1:getEmployees1>
<ns1:empno></ns1:empno>
</ns1:getEmployees1>
</soap:Body>
</soap:Envelope>
anybody seen this? - this sounds like a real bug to me..
thx clemens
I'm not sure that the support for jaxws annotations is ready and
integrated in the build yet, although it may be pretty close.
Raymond, it looks like you've been working on the interface-java-jaxws
module recently, can you give us its status?
Thanks.
I don't think the code in the interface-java-jaxws module is enough to
solve this problem. We also need the ability to generate a WSDL interface
at runtime from a Java interface containing JAX-WS annotations. (Our
current code for this uses Axis2, which doesn't understand JAX-WS
annotations.) The code we need would do the same as the JAX-WS tool
wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
be done at runtime and would generate WSDL to a stream instead of a file.
From a quick look at both these options, it looks like it would be
possible for the Tuscany runtime to call into code from either CXF or
the JAX-WS tools to do the generation. However, this wouldn't be using
any official APIs but would require a bit of copying and adapting the code
that is currently there. Of the two options, the CXF code seems rather
easier to work with. Also, since CXF is an Apache project, Tuscany could
contribute back to CXF any modifications we make to enable this.
Before I launch into actually trying to get this working, does anyone
else have comments or suggestions on the general approach?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
