given that I have a full testcase on my box with SDO generated through oracle 
adf bc, I guess I am happy to play guinea pig ..

/clemens

-----Original Message-----
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 10, 2008 9:56 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as
service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring
the namespace


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: <tuscany-dev@ws.apache.org>
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]

Reply via email to