Re: [VOTE] Release 2.0-Beta4 RC1
On Mon, Mar 12, 2012 at 3:24 AM, Nirmal Fernando nirmal070...@gmail.com wrote: Hi Ant, On Mon, Mar 12, 2012 at 3:19 AM, ant elder ant.el...@gmail.com wrote: On Sun, Mar 11, 2012 at 3:41 AM, Luciano Resende luckbr1...@gmail.com wrote: On Thu, Mar 8, 2012 at 1:48 AM, ant elder ant.el...@gmail.com wrote: Here's the release vote for RC1 of the 2.0-Beta4 artifacts, please review and vote. You can find the staged artifacts at: http://people.apache.org/~antelder/tuscany/2.0-Beta4-RC1/ and the SVN tag for the release at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta4-RC1/ The SVN command (svn log -r 1151792:HEAD https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta4) in the changes file should be corrected to svn log -r 1151792:HEAD https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta4-RC1 Isn't it? Hi Nirmal, when the vote passes and this is officially released the tag will be renamed from 2.0-Beta4-RC1 to 2.0-Beta4 so then the command will be correct. ...ant
Re: [VOTE] Release 2.0-Beta4 RC1
On Mon, Mar 12, 2012 at 3:28 AM, Nirmal Fernando nirmal070...@gmail.com wrote: Also shouldn't Release note be changed? http://people.apache.org/~antelder/tuscany/2.0-Beta4-RC1/RELEASE_NOTES Yes. Searching through the release it looks like that is the only place that hasn't been changed, the CHANGES file for example has been updated. Seems a shame to have to respin to change a single occurrence of a 3 character to be a 4 so lets wait and see if any issues come up or if it gets another +1 as is. ..ant
[jira] [Assigned] (TUSCANY-4027) EndpointFinder is ineffective
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4027: --- Assignee: Simon Laws EndpointFinder is ineffective - Key: TUSCANY-4027 URL: https://issues.apache.org/jira/browse/TUSCANY-4027 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Attachments: TUSCANY-4027.patch SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder. I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference(). This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder. -- 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-4027) EndpointFinder is ineffective
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4027. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Thanks for the patch Greg, Committed at revision: 1299664 EndpointFinder is ineffective - Key: TUSCANY-4027 URL: https://issues.apache.org/jira/browse/TUSCANY-4027 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4027.patch SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder. I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference(). This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder. -- 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: GSoC 2012 Idea : TUSCANY-4023
Hi, Dishara. Thank you for the interest. I'll elaborate more on the idea. There is a SCA domain concept in Tuscany, which is a service registry of metadata about all the components and policies. A composite application can have components running on different machines and they can be wired to each other using remote bindings within the SCA domain. From the runtime perspective, Tuscany uses the domain registry to resolve the wirings between components. Tuscany has two types of implementation of the domain registry at this point: 1) Local registry (which only knows the local endpoints). It can be extended to use local files to describe remote endpoints in the node.xml. 2) Multicast based registry on top of Tomcat Tribes or Hazelcast. In a typical enterprise environment, the multicast doesn't work well due to networking constraints. A more useful infrastructure is that we have centralized registry with HA configurations (such as master/slave). Apache ZooKeeper and Redis can be used for these purposes. The project will be mostly implement the DomainRegistry SPI [2]. [1] https://cwiki.apache.org/TUSCANYWIKI/distributed-runtime.html [2] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/core-spi/src/main/java/org/apache/tuscany/sca/runtime/DomainRegistry.java Thanks, Raymond On Mar 11, 2012, at 10:13 AM, Dishara Wijewardana wrote: Hi all, This is regarding the project idea Develop a distributed domain registry using Apache ZooKeeper, Redis, or Memcache. I am interested in applying for this SoC program and I saw the JIRA[1] project idea for Apache Tuscany. I have played with Tuscany and already had hands on experience with creating Tuscany SCA components in webapps and using the callback method and etc (the framework is very helpful when communicating between front end and back end). I would like to work on the project Develop a distributed domain registry using Apache ZooKeeper, Redis, or Memcache . These days I started looking in to Apache ZooKeeper and get familiar with it. It will be nice if I can get to know some details(what is the expected scope, what things need to be looked before hand, and etc) of this project idea, so that I can prepare well for the project. Thanks /Dishara
Spring services not considering Spring Framework based beans
It seems that we explicitly filter org.springframework beans in SpringXMLComponentTypeLoader.isValidBeanForService which cause issues if we are trying to wire to spring beans. Is this per spec ? With spring growing in scope, is this still something we want to continue doing ? BTW, Anyone has a link for the most recent Spring Spec ? Seems like OSOA is down and I can't find one in OASIS. Thanks -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
