[ 
https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wojtek Janiszewski updated TUSCANY-2469:
----------------------------------------

    Attachment: sca-binding-sdo-problem-jira-2469-30-july.patch

Hi,
this patch adds some functionality, it's also help request for problem I 
couldn't manage.

What was done and works:
1. binding-corba-runtime module reorganization to allow creating SCA binding 
over CORBA
2. Passing JAXB objects in CORBA SCA binding
3. JUnit tests in itest/corba (they fail due to problem described below, remove 
tuscany-databinding-sdo dependency to get 2 of 3 tests working)

Problems:
1. WSDLInterfaceContract creation
I've reused binding-ws-wsdlgen module to create interface contract. It fails at 
org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.addResolvedXSDs at line 
165. I've tried some debugging as well as creating interface contract from 
scratch and still have no idea how to handle creating WSDLInterfaceContract. 
Any thoughts, clues?

Thanks,
Wojtek

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, 
> sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba 
> binding, as a lightweight alternate to the current SOAP/Axis2 based 
> implementation.
> This implementation should be as transparent to the application developer and 
> assembler as the current default binding implementation (i.e. not impose 
> special constraints on the service interfaces, or additional codegen or 
> deployment or admin steps). We should also make sure that it is able to flow 
> instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is 
> easily pluggable / replaceable by others who decide to integrate Tuscany but 
> want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to