tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wojtek Janiszewski (JIRA)" <...@tuscany.apache.org>
Subject [jira] Commented: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding
Date Fri, 01 Aug 2008 22:39:32 GMT

    [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619155#action_12619155

Wojtek Janiszewski commented on TUSCANY-2469:

I've commited change under r681871. Now SCA default binding over CORBA creates name server
for service bindings which points to localhost (it results from transparent nature of SCA
def. binding - now user doesn't need to create name server seperately).
I'd also like to allow user to create name servers in <binding.corba>, by using another
attribute in configuration, ie. 
<binding.sca uri="corbaname::localhost:5080#ScenarioFourReuse" createNameServer="true"/>


> 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
>            Assignee: Raymond Feng
>             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.

View raw message