Re: [NOTICE] Jennifer Thompson voted as a Tuscany Committer
Congrats, Jennifer! Florian On Mon, Feb 6, 2012 at 10:11 AM, Jean-Sebastien Delfino jsdelf...@apache.org wrote: Welcome! - Jean-Sebastien On Sun, Feb 5, 2012 at 7:59 AM, Simon Laws simonsl...@googlemail.comwrote: On Fri, Feb 3, 2012 at 11:32 PM, Raymond Feng enjoyj...@gmail.com wrote: Welcome on board, Jennifer! Raymond On Feb 3, 2012, at 1:30 AM, ant elder wrote: The Tuscany PMC have voted to make Jennifer a Tuscany committer in recognition of all the patches submitted, particularly for the JMS binding. Congratulations and welcome Jennifer! ...ant Congrats Jennifer. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Closed] (TUSCANY-4011) Callback binding gets overriden and other issues
[ https://issues.apache.org/jira/browse/TUSCANY-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4011. --- Resolution: Fixed Closing as change was committed at rev1242412 Callback binding gets overriden and other issues Key: TUSCANY-4011 URL: https://issues.apache.org/jira/browse/TUSCANY-4011 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding. In trying to work out what was going on here I noticed a couple of other things that I'd like to improve: - The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint - There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it
Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it -- Key: TUSCANY-4013 URL: https://issues.apache.org/jira/browse/TUSCANY-4013 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 The BindingURIBuilder overwrites any URI provided by the user so I propose to add a new field to binding (userSpecifiedURI) to hold what the user originally typed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it
[ https://issues.apache.org/jira/browse/TUSCANY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206168#comment-13206168 ] Simon Laws commented on TUSCANY-4013: - I've just noticed that the binding model is all over the pace in terms of what extended what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. I wanted this fix for binding.ws so I'll fix that first and raise a separate JIRA to tidy up the binding models. Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it -- Key: TUSCANY-4013 URL: https://issues.apache.org/jira/browse/TUSCANY-4013 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 The BindingURIBuilder overwrites any URI provided by the user so I propose to add a new field to binding (userSpecifiedURI) to hold what the user originally typed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4014) Tidy up the binding model hierarchy
Tidy up the binding model hierarchy --- Key: TUSCANY-4014 URL: https://issues.apache.org/jira/browse/TUSCANY-4014 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 As per TUSCANY-4013 the binding model is all over the pace in terms of what extends what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. Would be good to tidy this up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4014) Tidy up the binding model hierarchy
[ https://issues.apache.org/jira/browse/TUSCANY-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206352#comment-13206352 ] Luciano Resende commented on TUSCANY-4014: -- It seems that we have the following : BaseBindingImpl (located in core-spi) and not really used by anyone BindingImpl (located in assembly) and used by CorbaBindingImpl, HazelcastBinding and HazelcastBinding It seems safe to remove BaseBindingImpl, but before that, maybe update BindingImpl with some of it's model (e.g. unresolved and support for wireFormats and operationSelector models) Another option is to get rid of both, and make the three bindings handle the binding model itself, as all other bindings are doing. Tidy up the binding model hierarchy --- Key: TUSCANY-4014 URL: https://issues.apache.org/jira/browse/TUSCANY-4014 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 As per TUSCANY-4013 the binding model is all over the pace in terms of what extends what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. Would be good to tidy this up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TUSCANY-4014) Tidy up the binding model hierarchy
[ https://issues.apache.org/jira/browse/TUSCANY-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206352#comment-13206352 ] Luciano Resende edited comment on TUSCANY-4014 at 2/12/12 7:12 AM: --- It seems that we have the following : BaseBindingImpl (located in core-spi) seems to be only used by LifecycleBinding in testing BindingImpl (located in assembly) and used by CorbaBindingImpl, HazelcastBinding and HazelcastBinding It seems safe to remove BaseBindingImpl, but before that, maybe update BindingImpl with some of it's model (e.g. unresolved and support for wireFormats and operationSelector models) Another option is to get rid of both, and make the three bindings handle the binding model itself, as all other bindings are doing. was (Author: luciano resende): It seems that we have the following : BaseBindingImpl (located in core-spi) and not really used by anyone BindingImpl (located in assembly) and used by CorbaBindingImpl, HazelcastBinding and HazelcastBinding It seems safe to remove BaseBindingImpl, but before that, maybe update BindingImpl with some of it's model (e.g. unresolved and support for wireFormats and operationSelector models) Another option is to get rid of both, and make the three bindings handle the binding model itself, as all other bindings are doing. Tidy up the binding model hierarchy --- Key: TUSCANY-4014 URL: https://issues.apache.org/jira/browse/TUSCANY-4014 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 As per TUSCANY-4013 the binding model is all over the pace in terms of what extends what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. Would be good to tidy this up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
