Tuscany board report is due
The Tuscany board report is due this week, i'll prepare a draft but let me know if there is something you want mentioned. ...ant
[jira] [Commented] (TUSCANY-3519) *!* Develop a manager webapp for Tuscany Tomcat embedded runtime
[ https://issues.apache.org/jira/browse/TUSCANY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202253#comment-13202253 ] ant elder commented on TUSCANY-3519: There is a student already asking to do this one for GSoC 2012 *!* Develop a manager webapp for Tuscany Tomcat embedded runtime -- Key: TUSCANY-3519 URL: https://issues.apache.org/jira/browse/TUSCANY-3519 Project: Tuscany Issue Type: New Feature Components: Java SCA Community Ideas Reporter: ant elder Labels: gsoc, gsoc2010, gsoc2011, gsoc2012, mentor Fix For: Java-SCA-2.x The goal of this project is to create a new web application for managing the Apache Tuscany runtime thats embedded in Apache Tomcat. Tomcat already has a simple Java web application for managing its web applications so you could take that source as the starting point and and update it to support using SCA contributions instead of JEE webapps. Using that existing application as a starting point should enable you to to make a lot of progress quite quickly and end up with something that is demonstrably useful in the short timeframe of this GSOC project. Feel welcome to email if you want more information: ant.el...@gmail.com -- 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] [Closed] (TUSCANY-4001) Error handling in JMSBindingProcessor.read could be improved for UnexpectedElement
[ https://issues.apache.org/jira/browse/TUSCANY-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4001. -- Resolution: Fixed I've updated the code to use the QName when its available in the error message Error handling in JMSBindingProcessor.read could be improved for UnexpectedElement -- Key: TUSCANY-4001 URL: https://issues.apache.org/jira/browse/TUSCANY-4001 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: ant elder Priority: Minor Fix For: Java-SCA-2.x Error handling in JMSBindingProcessor.read could be improved for UnexpectedElement. For example, when processing a .composite file which contained wireFormat.jmsdefault in the Tuscany namespace the following exception was thrown: Incomplete binding.jms definition found unexpected element: org.apache.tuscany.sca.assembly.impl.ExtensionImpl@21e7c65 (FYI, the correct element should have been wireFormat.jmsDefault in the OASIS SCA namespace.) I had to run with a debugger to determine what the offending element was. It would be more useful to know the QName rather than the classtype hash code. -- 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
Re: Tuscany board report is due
On Tue, Feb 7, 2012 at 11:44 AM, ant elder ant.el...@gmail.com wrote: The Tuscany board report is due this week, i'll prepare a draft but let me know if there is something you want mentioned. ...ant The only thing that comes to mind is the addition of a committer. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Created] (TUSCANY-4011) Callback binding gets overriden and other issues
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] [Closed] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3932. --- Resolution: Fixed Am closing this now as I think the specific issue is solved. I've opened TUSCANY-4011 as a follow up with some other callback issues/improvements Callbacks don't work in the distributed domain -- Key: TUSCANY-3932 URL: https://issues.apache.org/jira/browse/TUSCANY-3932 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 The callback wire calculation currently requires knowledge of the service runtime. This will not be available in the distributed case where the Endpoint matched by and retrieved from the registry will not have a built runtime behind it. We need to refactor this based on the configuration available in the SCDL written to represent a remote Endpoint. Of particular interest is callback bindings that are generated vs callback bindings that are specified by the user. If a user specifies a binding this should automatically be available in the reference node as it will be written be default when the Endpoint is written out. Automatically generated callback bindings, usually generated to match the forward binding, won't be in that list and won't get written out so we need to address that. -- 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-4012) Callback performance improvement
Callback performance improvement Key: TUSCANY-4012 URL: https://issues.apache.org/jira/browse/TUSCANY-4012 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Separating this out from TUSCANY-4011 - There is an opportunity to optimize callbacks if a binding implementation 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. The address will have to be cached in the CallbackServiceReference (or close by) so that when the callback message is sent the URI can be transmitted to the callback reference binding implementation which can then set/reset the target URI. -- 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
