GSoC 2012 Idea : TUSCANY-4023

2012-03-11 Thread Dishara Wijewardana
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


[jira] [Created] (TUSCANY-4027) EndpointFinder is ineffective

2012-03-11 Thread Greg Dritschler (Created) (JIRA)
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
Priority: Minor


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] [Updated] (TUSCANY-4027) EndpointFinder is ineffective

2012-03-11 Thread Greg Dritschler (Updated) (JIRA)

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

Greg Dritschler updated TUSCANY-4027:
-

Attachment: TUSCANY-4027.patch

 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
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] [Commented] (TUSCANY-4026) XSDModelResolver fails to initiate WSDL model resolution for inline schemas

2012-03-11 Thread Simon Laws (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/TUSCANY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227198#comment-13227198
 ] 

Simon Laws commented on TUSCANY-4026:
-

Hi Kaushik

I tried to apply the patch but there seems to be some changes missing. The 
patch applies a dependency from xsd to interface-wsdl. However there is already 
a dependency in the opposite direction. How did you get round this in your 
build?



 XSDModelResolver fails to initiate WSDL model resolution for inline schemas
 ---

 Key: TUSCANY-4026
 URL: https://issues.apache.org/jira/browse/TUSCANY-4026
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Databinding-SDO
Affects Versions: Java-SCA-2.x
Reporter: Kaushik Mukherjee
 Attachments: JIRA-4206.patch


 XSDModelResolver fails to initiate WSDLModelResolver for inline schemas 
 during start so there is no inline schema document object model added to the 
 contribution. When we try to resolve the namespace and type associated with 
 the inline schema we fail to find the document since it was never built.

--
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: [VOTE] Release 2.0-Beta4 RC1

2012-03-11 Thread ant elder
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/

   ...ant


 Seems good, source distribution builds from a clean repo, run RAT and
 things seems fine.

 +1


Thanks Luciano. +1 from me too.

   ...ant


Re: [VOTE] Release 2.0-Beta4 RC1

2012-03-11 Thread Nirmal Fernando
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?


...ant
 
 
  Seems good, source distribution builds from a clean repo, run RAT and
  things seems fine.
 
  +1
 

 Thanks Luciano. +1 from me too.

   ...ant




-- 
Best Regards,
Nirmal

C.S.Nirmal J. Fernando
Software Engineer,
WSO2 Inc.

Blog: http://nirmalfdo.blogspot.com/


Re: [VOTE] Release 2.0-Beta4 RC1

2012-03-11 Thread Nirmal Fernando
Also shouldn't Release note be changed?
http://people.apache.org/~antelder/tuscany/2.0-Beta4-RC1/RELEASE_NOTES

On Mon, Mar 12, 2012 at 8:54 AM, Nirmal Fernando nirmal070...@gmail.comwrote:

 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?

 
...ant
 
 
  Seems good, source distribution builds from a clean repo, run RAT and
  things seems fine.
 
  +1
 

 Thanks Luciano. +1 from me too.

   ...ant




 --
 Best Regards,
 Nirmal

 C.S.Nirmal J. Fernando
 Software Engineer,
 WSO2 Inc.

 Blog: http://nirmalfdo.blogspot.com/




-- 
Best Regards,
Nirmal

C.S.Nirmal J. Fernando
Software Engineer,
WSO2 Inc.

Blog: http://nirmalfdo.blogspot.com/