[jira] [Commented] (TUSCANY-4072) Tuscany fails to retrieve XSD type/element for nested WSDL with diff namespace(wsdl resolver issue)
[
https://issues.apache.org/jira/browse/TUSCANY-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13491385#comment-13491385
]
ant elder commented on TUSCANY-4072:
Thanks for the update Robin, I've committed the updated fix and test after the
IM chat we had. I do still get some asserts failing in the test even with the
fix applied so i've commented them out with the comment // TODO: fails, could
you take a look and see why they are failing? The testcase is at:
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/testing/itest/nested-wsdl/
Tuscany fails to retrieve XSD type/element for nested WSDL with diff
namespace(wsdl resolver issue)
---
Key: TUSCANY-4072
URL: https://issues.apache.org/jira/browse/TUSCANY-4072
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0-Beta3
Reporter: Robin Yu
Priority: Critical
Attachments: TUSCANY-4072.zip
This issue is found on WAS8.5 while we used tunscany wsdl model resolver to
resolve one nested WSDL(diff Namespace) case:
org.apache.tuscany.sca.interfacedef.wsdl.impl.InvalidWSDLException: Element
cannot be resolved: {http://OrderService/OrderService/importwsdl}retrieveOrder
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl$WSDLPart.init(WSDLOperationIntrospectorImpl.java:276)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getMessageType(WSDLOperationIntrospectorImpl.java:194)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getInputType(WSDLOperationIntrospectorImpl.java:145)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:214)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.getOperation(WSDLInterfaceIntrospectorImpl.java:87)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.introspectOperations(WSDLInterfaceIntrospectorImpl.java:67)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceIntrospectorImpl.introspectPortType(WSDLInterfaceIntrospectorImpl.java:78)
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLFactoryImpl.createWSDLInterface(WSDLFactoryImpl.java:56)
at
com.ibm.bpmsdk.scaruntime.sca.binding.jaxws.nestedwsdl.multi.inlineschemas.NestedInlineSchemasWSDLResolverTestCase.testCreateInterfaceContract(NestedInlineSchemasWSDLResolverTestCase.java:138)
at
com.ibm.bpmsdk.scaruntime.sca.binding.jaxws.nestedwsdl.multi.inlineschemas.NestedInlineSchemasWSDLResolverTestCase.testNestedWSDLMultiInlineSchemasParsing(NestedInlineSchemasWSDLResolverTestCase.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4070) build problem due to axis2/rampart 1.5 dependency
[ https://issues.apache.org/jira/browse/TUSCANY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4070. -- Resolution: Fixed I've added a dependency definition to the binding-ws-runtime-axis2 pom.xml which should fix this. Works for me now so give it a try. build problem due to axis2/rampart 1.5 dependency -- Key: TUSCANY-4070 URL: https://issues.apache.org/jira/browse/TUSCANY-4070 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-2.0-Beta3 Reporter: Tom Seelbach Tuscany module binding-ws-runtime-axis2 depends on axis2 1.5.3 and rampart 1.5.1 But axis2/rampart 1.5 branch uses repository http://shibboleth.internet2.edu/downloads/maven2/ which has gone away: http://svn.apache.org/repos/asf/axis/axis2/java/rampart/branches/1_5/pom.xml repository ... idopen-saml/id nameOpenSAML/name urlhttp://shibboleth.internet2.edu/downloads/maven2//url Even though shibboleth.internet2.edu is gone, if you build tuscany from scratch it will cause a bogus copy of http://central.maven.org/maven2/org/apache/apache/8/apache-8.pom to be put in your maven repository. I think the fix is to build binding-ws-runtime-axis2 with axis2/rampart 1.6.2 but i don't know the impact on all the exclusions etc in that pom.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4069) Issue with resolving autowired reference when binding is not defined to a target service exposed over multiple bindings
[
https://issues.apache.org/jira/browse/TUSCANY-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder closed TUSCANY-4069.
--
Resolution: Fixed
Patch applied, thanks for the fix Rashmi.
Issue with resolving autowired reference when binding is not defined to a
target service exposed over multiple bindings
-
Key: TUSCANY-4069
URL: https://issues.apache.org/jira/browse/TUSCANY-4069
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0-Beta3
Reporter: Rashmi Hunt
This issue is somewhat similar to TUSCANY-3941, with difference that the
autowired reference without
any binding defined, gets matched to a first binding on the target service
with multiple bindings even
though binding.sca is one of them.
E.g
component name=Calculator autowire=true
implementation.java class=test.sca.calculator.Calculator/
service name=CalculatorService
binding.sca/
/service
reference name=add multiplicity=1..1
interface.java interface=test.sca.add.AddLocal/
/reference
/component
component name=Add
implementation.java class=test.sca.add.AddDelegate/
service name=AddLocal
binding.ws name=ws/
binding.sca/
/service
/component
Since above autowired reference add in component Calculator is defined
without any binding, I would
think the runtime would match it to binding.sca of the target Service.
Instead for this reference,
runtime matches to first binding of the target service, which is binding.ws
instead of matching to
binding.sca even though binding.sca is one of the bindings defined in the
target service.
Fix can be, in EndpointReferenceBinderImpl.selectForwardEndpoint(..) add
below logic,
if (endpointReference.getBinding() == null
endpointReference.getReference().getAutowire() == true){
for (Endpoint endpoint : matchedEndpoints){
if (endpoint.getBinding() instanceof SCABinding){
matchedEndpoint = endpoint;
break;
}
}
}
after,
// TUSCANY-3941 check for the case where the user has provided a
// binding.sca at the reference and make sure we pick
// a binding.sca at the service regardless of how
many
// other bindings are provided
if (endpointReference.getBinding() != null
endpointReference.getBinding() instanceof SCABinding ){
for (Endpoint endpoint : matchedEndpoints){
if (endpoint.getBinding() instanceof SCABinding){
matchedEndpoint = endpoint;
break;
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4068) WSDL resources are not found from dependent contributions
ant elder created TUSCANY-4068: -- Summary: WSDL resources are not found from dependent contributions Key: TUSCANY-4068 URL: https://issues.apache.org/jira/browse/TUSCANY-4068 Project: Tuscany Issue Type: Bug Reporter: ant elder Fix For: Java-SCA-2.x Reporting this from a user: If a contribution imports a namespace from a dependent contribution that exports the namespace then wsdl resources which use that namespace are not found using the context classloader. -- 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-4068) WSDL resources are not found from dependent contributions
[
https://issues.apache.org/jira/browse/TUSCANY-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13427878#comment-13427878
]
ant elder commented on TUSCANY-4068:
This is happening because its not yet implemented - the code of
ClassLoaderModelResover.findResource method just has a TODO comment saying this
needs to be done:
public URL findResource(String name) {
//TODO delegate to the Java import resolvers
URL url = super.findResource(name);
return url;
}
WSDL resources are not found from dependent contributions
-
Key: TUSCANY-4068
URL: https://issues.apache.org/jira/browse/TUSCANY-4068
Project: Tuscany
Issue Type: Bug
Reporter: ant elder
Fix For: Java-SCA-2.x
Reporting this from a user: If a contribution imports a namespace from a
dependent contribution that exports the namespace then wsdl resources which
use that namespace are not found using the context classloader.
--
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-4067) WSDL not found in contribution with nested jars
[ https://issues.apache.org/jira/browse/TUSCANY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424744#comment-13424744 ] ant elder commented on TUSCANY-4067: The only way i can see to fix this properly is to have all nested archives extracted from the contribution when its installed and then process the extracted archives with the contribution processor adding the artifacts to the original contribution, so thats what i'll do unless anyone can think of a better approach. WSDL not found in contribution with nested jars --- Key: TUSCANY-4067 URL: https://issues.apache.org/jira/browse/TUSCANY-4067 Project: Tuscany Issue Type: Bug Reporter: ant elder Reporting this from a user: Migrating from OSOA to OASIS SCA and contributions that have nested jars containing wsdl document no longer work as the wsdl is not found -- 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-4067) WSDL not found in contribution with nested jars
ant elder created TUSCANY-4067: -- Summary: WSDL not found in contribution with nested jars Key: TUSCANY-4067 URL: https://issues.apache.org/jira/browse/TUSCANY-4067 Project: Tuscany Issue Type: Bug Reporter: ant elder Reporting this from a user: Migrating from OSOA to OASIS SCA and contributions that have nested jars containing wsdl document no longer work as the wsdl is not found -- 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-4066) WrapperInfo clone does not copy for unwrappedType datatype
[ https://issues.apache.org/jira/browse/TUSCANY-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4066. -- Resolution: Fixed Fix applied in r1359519. Thanks for the fix Hasan. WrapperInfo clone does not copy for unwrappedType datatype -- Key: TUSCANY-4066 URL: https://issues.apache.org/jira/browse/TUSCANY-4066 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.0 Environment: All Reporter: Hasan Muhammad Priority: Minor Fix For: Java-SCA-2.0 The WapperInfo clone does not do a deep copy of unwrappedType datatype. This seemed to have regressed after Tuscany-3890. I will be sending in the fix to Ant. With this bug, one would see a ClassCastException such as the following java.lang.ClassCastException: org.apache.xerces.dom.ElementNSImpl incompatible with org.apache.axiom.om.OMElement at org.apache.tuscany.sca.databinding.axiom.OMElementWrapperHandler.setChild(OMElementWrapperHandler.java:91) at org.apache.tuscany.sca.databinding.axiom.OMElementWrapperHandler.setChildren(OMElementWrapperHandler.java:77) at org.apache.tuscany.sca.databinding.axiom.OMElementWrapperHandler.setChildren(OMElementWrapperHandler.java:50) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:213) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46) at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:209) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:116) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediateInput(MediatorImpl.java:444) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.processRequest(DataTransformationInterceptor.java:69) at org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invokeAsyncRequest(InterceptorAsyncImpl.java:65) -- 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 Tuscany SCA 2.0 RC2
Well +1 from me anyway, would anyone else have a vote? ...ant On Tue, Jun 19, 2012 at 10:02 AM, ant elder ant.el...@gmail.com wrote: Here's the 2.0 RC2 release artifacts, please review and vote. The distributions and staging maven repo are at: http://people.apache.org/~antelder/tuscany/2.0-RC2/ The SVN tag: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-RC2/ ...ant
[RESULT][VOTE] Release Tuscany SCA 2.0 RC2
Woohoo. Passed with four +1 votes. Thanks everyone. ...ant On Sun, Jun 24, 2012 at 8:38 PM, Simon Laws simonsl...@googlemail.com wrote: On Sun, Jun 24, 2012 at 10:58 AM, Nirmal Fernando nirmal070...@gmail.com wrote: +1 for the release! Thanks Ant for the hard work you've put in, on getting this release in!! On Sun, Jun 24, 2012 at 3:13 PM, ant elder ant.el...@gmail.com wrote: Well +1 from me anyway, would anyone else have a vote? ...ant On Tue, Jun 19, 2012 at 10:02 AM, ant elder ant.el...@gmail.com wrote: Here's the 2.0 RC2 release artifacts, please review and vote. The distributions and staging maven repo are at: http://people.apache.org/~antelder/tuscany/2.0-RC2/ The SVN tag: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-RC2/ ...ant -- Best Regards, Nirmal C.S.Nirmal J. Fernando Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/ I second that, thanks Ant for sticking with it when I've not been very responsive. +1 from me Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[VOTE] Release Tuscany SCA 2.0 RC2
Here's the 2.0 RC2 release artifacts, please review and vote. The distributions and staging maven repo are at: http://people.apache.org/~antelder/tuscany/2.0-RC2/ The SVN tag: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-RC2/ ...ant
Re: Ubuntu specific compilation issues
The nightly builds run on Ubuntu and they don't see that fail, I'd guess its likely an issue with that OpenJDK version. ...ant On Sat, Jun 16, 2012 at 7:46 PM, Luciano Resende luckbr1...@gmail.com wrote: It seems that there are some compilation issues in latest ubuntu after recent java updates. And I don't see any issues in Mac OS environment... Environment information : $ java -version java version 1.6.0_24 OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-4ubuntu3) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) Compilation Error : [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /home/lresende/opensource/apache/tuscany/java-sca-2.x/modules/core/src/main/java/org/apache/tuscany/sca/core/context/impl/ComponentContextImpl.java:[106,32] type parameters of RR cannot be determined; no unique maximal instance exists for type variable R with upper bounds org.oasisopen.sca.ServiceReferenceB,org.oasisopen.sca.ServiceReferenceB [ERROR] /home/lresende/opensource/apache/tuscany/java-sca-2.x/modules/core/src/main/java/org/apache/tuscany/sca/core/invocation/ExtensibleProxyFactory.java:[60,43] invalid inferred types for R; inferred type does not conform to declared bound(s) inferred: org.oasisopen.sca.ServiceReferenceB bound(s): org.oasisopen.sca.ServiceReferenceB [ERROR] /home/lresende/opensource/apache/tuscany/java-sca-2.x/modules/core/src/main/java/org/apache/tuscany/sca/core/invocation/ExtensibleProxyFactory.java:[62,39] invalid inferred types for R; inferred type does not conform to declared bound(s) inferred: org.oasisopen.sca.ServiceReferenceB bound(s): org.oasisopen.sca.ServiceReferenceB [INFO] 3 errors [INFO] - [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/lresende/opensource/apache/tuscany/java-sca-2.x/modules/core/src/main/java/org/apache/tuscany/sca/core/context/impl/ComponentContextImpl.java:[106,32] type parameters of RR cannot be determined; no unique maximal instance exists for type variable R with upper bounds org.oasisopen.sca.ServiceReferenceB,org.oasisopen.sca.ServiceReferenceB /home/lresende/opensource/apache/tuscany/java-sca-2.x/modules/core/src/main/java/org/apache/tuscany/sca/core/invocation/ExtensibleProxyFactory.java:[60,43] invalid inferred types for R; inferred type does not conform to declared bound(s) inferred: org.oasisopen.sca.ServiceReferenceB bound(s): org.oasisopen.sca.ServiceReferenceB /home/lresende/opensource/apache/tuscany/java-sca-2.x/modules/core/src/main/java/org/apache/tuscany/sca/core/invocation/ExtensibleProxyFactory.java:[62,39] invalid inferred types for R; inferred type does not conform to declared bound(s) inferred: org.oasisopen.sca.ServiceReferenceB bound(s): org.oasisopen.sca.ServiceReferenceB I'll investigate it further later tonight or tomorrow, but we might want to fix this before the new RC -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Comet binding
I've taken the comet binding out of the trunk build because the old atmosphere dependency its using has had its dependencies moved in the maven repositories and now doesn't work. The nightly trunk build has been failing due to this for nearly two months now and we need to do something about it to get the 2.0 release out. I've tried adding pom.xmls files to the tuscany repo to fix it but that the old ones seem to take precedence and i've tried updating to newer releases of atmosphere but can't get the comet binding to work with them and i don't have any more time to try to fix it. ...ant
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Thu, Jun 7, 2012 at 8:55 PM, Luciano Resende luckbr1...@gmail.com wrote: On Wed, Jun 6, 2012 at 4:18 AM, ant elder ant.el...@gmail.com wrote: Ok a few weeks have past now and there have been some updates and fixes done. If i create a new RC would anyone vote for it now? Is there anything else anyone thinks must be done still before they would vote for the 2.0 release? ...ant I want to properly fix the Widget issues from trunk and would appreciate couple days. We could target cutting the new RC over the weekend or by Monday. Sure ok, i had respun and started uploading a new RC yesterday but its fine to bin than and lets cut a new RC on Monday then. Any other help you might need with that ? Any help with reviewing the current state of trunk samples, builds etc before Monday would be great. ...ant
[jira] [Closed] (TUSCANY-4057) Toplevel INSTALL* for Tuscany binary (improvment)
[ https://issues.apache.org/jira/browse/TUSCANY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4057. -- Resolution: Fixed File updated, thanks Andrew Toplevel INSTALL* for Tuscany binary (improvment) - Key: TUSCANY-4057 URL: https://issues.apache.org/jira/browse/TUSCANY-4057 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta3 Reporter: Andrew Potter Priority: Trivial Attachments: INSTALL Tentative change for the main install instructions*, added clearer instruction and direction. New INSTALL* attached. *Edit -- 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-4062) trunk\samples\README additions (improvement)
[ https://issues.apache.org/jira/browse/TUSCANY-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4062. -- Resolution: Fixed Updates applied, thanks Andrew trunk\samples\README additions (improvement) Key: TUSCANY-4062 URL: https://issues.apache.org/jira/browse/TUSCANY-4062 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Reporter: Andrew Potter Priority: Trivial Labels: documentation Attachments: README Added a lot of content to the README in the main samples directory, for clarity and direction. -- 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-4058) itest/distribution/legal-checks build failure with IBM JDK
[
https://issues.apache.org/jira/browse/TUSCANY-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder closed TUSCANY-4058.
--
Resolution: Fixed
Updates applied, thanks for the fixes Andrew
itest/distribution/legal-checks build failure with IBM JDK
--
Key: TUSCANY-4058
URL: https://issues.apache.org/jira/browse/TUSCANY-4058
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.x
Environment: IBM JDK
Reporter: Andrew Potter
Priority: Blocker
Labels: build-failure
Two jars are included with the IBM JDK that are not included in the license,
causing a build failure. The offending jars are bcel-5.2.jar and
jakarta-regexp-1.4.jar. To fix, add two lines to the if statement in:
trunk\testing\itest\distribution\legal-checks\src\test\java\itest\JarsInLICENSETestCase.java
Starting at line 104, the if block should be as follows:
if (jar.startsWith(tuscany-) || jar.startsWith(sample-)
|| jar.startsWith(test-) || jar.startsWith(itest-)) {
// ignore tuscany jars as they're not mentioned in the
LICENSE file
} else if (System.getProperty(java.vendor).equals(IBM
Corporation) (jar.equals(bcel-5.2.jar) ||
jar.equals(jakarta-regexp-1.4.jar))) {
// ignore IBM JDK specific jars.
} else {
badJars.add(jar);
}
--
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-4059) Build failure for itest/policy/reliability with IBM JDK
[ https://issues.apache.org/jira/browse/TUSCANY-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4059. -- Resolution: Fixed Updated as suggested, thanks for the fix Andrew Build failure for itest/policy/reliability with IBM JDK --- Key: TUSCANY-4059 URL: https://issues.apache.org/jira/browse/TUSCANY-4059 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: IBM JDK Reporter: Andrew Potter Priority: Blocker Labels: build-failure Test code: assertTrue(StatusImpl.statusString.contains(atmostonce exactlyonce atleastonce)); but string returned from tests contains: atmostonce atleastonce exactlyonce. Possible fix, change test code from one line to: assertTrue(StatusImpl.statusString.contains(atmostonce)); assertTrue(StatusImpl.statusString.contains(exactlyonce)); assertTrue(StatusImpl.statusString.contains(atleastonce)); -- 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 Tuscany SCA 2.0 RC1
On Fri, May 11, 2012 at 12:51 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, May 11, 2012 at 12:49 PM, ant elder ant.el...@gmail.com wrote: On Thu, May 10, 2012 at 6:31 PM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:44 AM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:28 AM, Simon Laws simonsl...@googlemail.com wrote: ..snip Simon, It looks like you've not included the staging repo, the samples aren't finding the 2.0 pom's in Maven central because the release hasn't been published yet. doh - I'm getting out of practice. I'll try again. I can add a sentence to the top sample README saying what it is but what else if anything needs updating before doing a respin just for that? ...ant I'd like to run through the samples before a respin. Won't get to it until this evening. Simon I have just came back from vacation end of last week and I'm finally getting time to go over this and will send feedback soonish. On a related topic, would you guys be ok on waiting for finishing up Wink 1.2 release which a initial RC was done over the weekend, so that we can have it as part of the 2.0 release ? Ok, Wink 1.2 has been trough the voting process. I'll publish the artifacts and update Tuscany. Ok i see you've done that now, I could spin a new RC but there hasn't been much review of RC1 yet and there are still a bunch of issues that Simon raised (i've fixed all the getting started samples). Is anyone going to do any more reviews or fixes? ...ant I still want to do more on RC1 (but am being very slow, sorry). Maybe we should set a deadline for doing RC2. Another couple of weeks? Ok a few weeks have past now and there have been some updates and fixes done. If i create a new RC would anyone vote for it now? Is there anything else anyone thinks must be done still before they would vote for the 2.0 release? ...ant
[jira] [Assigned] (TUSCANY-4060) Dead links on 'running tuscany' sample documentation
[ https://issues.apache.org/jira/browse/TUSCANY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-4060: -- Assignee: ant elder Dead links on 'running tuscany' sample documentation Key: TUSCANY-4060 URL: https://issues.apache.org/jira/browse/TUSCANY-4060 Project: Tuscany Issue Type: Bug Components: Java SCA Documentation Affects Versions: Java-SCA-2.0-Beta3 Reporter: Jonathan Miodownik Assignee: ant elder Priority: Trivial Labels: Java-SCA-2.0-Beta3, docuentation Some of the links in the running Tuscany documentation provided in the samples are broken. These include instructions for ant, as well as jse. looking at the links, it seems like they were coded to look for their appropriate files in non-existent locations. Proposed solution to this is obviously to fix the links, and include documentation for those respective methods of starting a Tuscany SCA runtime. -- 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-4054) Build failure with itest/base/dependencies and itest/scdl
[ https://issues.apache.org/jira/browse/TUSCANY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4054. -- Resolution: Fixed Change applied, thanks for the fix Andrew Build failure with itest/base/dependencies and itest/scdl - Key: TUSCANY-4054 URL: https://issues.apache.org/jira/browse/TUSCANY-4054 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: EITHER Oracle or IBM JDK Reporter: Andrew Potter Priority: Blocker Labels: build-failure Build fails with exception: junit.framework.AssertionFailedError: expected:6 but was:12 This seems to have come about because of the new dependency for the Woodstox parser, with both the Oracle and IBM JDKs. The generated dependencies in target/dependencies are as follows: asm-3.1.jar bcel-5.2.jar cglib-2.2.jar jakarta-regexp-1.4.jar junit-4.8.1.jar stax-api-1.0.1.jar tuscany-base-runtime-2.0-SNAPSHOT.jar wsdl4j-1.6.2.jar wstx-asl-3.2.9.jar xalan-2.7.0.jar xml-apis-1.0.b2.jar XmlSchema-1.4.3.jar Possible fix, change line 55 of: trunk\testing\itest\base\dependencies\src\test\java\org\apache\tuscany\sca\itest\base\dependencies\ValidateDependenciesTestCase.java and line 52 of: C:\Users\IBM_ADMIN\Documents\Tuscany\Source\trunk\testing\itest\scdl\src\test\java\org\apache\tuscany\sca\itest\scdl\ValidateDependenciesTestCase.java to: Assert.assertEquals(12, dependencyFiles.length); as well as updating the comments in both files to include these dependencies, as long as they are accpetable. -- 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-4046) Build failure in sample helloworld-webservice with IBM JDK 7
[ https://issues.apache.org/jira/browse/TUSCANY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4046. -- Resolution: Fixed Updated as suggested, thanks for the fix Andrew Build failure in sample helloworld-webservice with IBM JDK 7 Key: TUSCANY-4046 URL: https://issues.apache.org/jira/browse/TUSCANY-4046 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: IBM JDK 7 Reporter: Andrew Potter Priority: Blocker Labels: build-failure Build fails with: IllegalArgumentException: The XMLInputFactory does not recognize the property reuse-instance. Reoccuring problem with IBM StAX parser, adding dependency for Woodstox parser fixes: dependency groupIdorg.codehaus.woodstox/groupId artifactIdwstx-asl/artifactId version3.2.9/version scopetest/scope /dependency -- 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-4045) Module binding-ws-runtime-axis2 build failure with IBM JDK
[ https://issues.apache.org/jira/browse/TUSCANY-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4045. -- Resolution: Fixed Update apply, thanks for the fix Andrew Module binding-ws-runtime-axis2 build failure with IBM JDK -- Key: TUSCANY-4045 URL: https://issues.apache.org/jira/browse/TUSCANY-4045 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: IBM JDK 7 Reporter: Andrew Potter Priority: Blocker Labels: build-failure Error with exception: java.lang.IllegalArgumentException: The XMLInputFactory does not recognize the property reuse-instance. due to the wrong StAX parser code being selected (I think). Adding the dependency for the Woodstox parser to binding-ws-runtime-axis2/pom.xml fixes this: dependency groupIdorg.codehaus.woodstox/groupId artifactIdwstx-asl/artifactId version3.2.9/version scopetest/scope /dependency -- 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-4044) Module policy-wspolicy build failure with IBM JDK
[ https://issues.apache.org/jira/browse/TUSCANY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4044. -- Resolution: Fixed Updated as suggested, thanks for the fix Andrew. Module policy-wspolicy build failure with IBM JDK - Key: TUSCANY-4044 URL: https://issues.apache.org/jira/browse/TUSCANY-4044 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: IBM JDK (x86-64) Reporter: Andrew Potter Priority: Blocker Labels: build-failure Running mvn clean install for module policy-wspolicy fails with: java.lang.IllegalStateException: The current state is not START_DOCUMENT. when using the IBM JDK, however the Oracle JDK works to build this module. Full stack trace: java.lang.IllegalStateException: The current state is not START_DOCUMENT. at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwIllegalStateException(StAXMessageProvider.java:46) at com.ibm.xml.xlxp.api.stax.XMLStreamReaderImpl.getCharacterEncodingScheme(XMLStreamReaderImpl.java:1580) at com.ibm.xml.xlxp.api.stax.XMLInputFactoryImpl$XMLStreamReaderProxy.getCharacterEncodingScheme(XMLInputFactoryImpl.java:353) at org.apache.tuscany.sca.common.xml.stax.reader.XMLDocumentStreamReader.getCharacterEncodingScheme(XMLDocumentStreamReader.java:145) at org.apache.axiom.om.impl.builder.StAXBuilder.init(StAXBuilder.java:126) at org.apache.axiom.om.impl.builder.StAXBuilder.init(StAXBuilder.java:164) at org.apache.axiom.om.impl.builder.StAXOMBuilder.init(StAXOMBuilder.java:157) at org.apache.tuscany.sca.policy.wspolicy.xml.WSPolicyProcessor.read(WSPolicyProcessor.java:91) at org.apache.tuscany.sca.policy.wspolicy.xml.WSPolicyProcessor.read(WSPolicyProcessor.java:58) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.read(DefaultStAXArtifactProcessorExtensionPoint.java:296) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:170) at org.apache.tuscany.sca.policy.xml.PolicySetProcessor.read(PolicySetProcessor.java:219) at org.apache.tuscany.sca.policy.xml.PolicySetProcessor.read(PolicySetProcessor.java:66) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.read(DefaultStAXArtifactProcessorExtensionPoint.java:296) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:170) at org.apache.tuscany.sca.definitions.xml.DefinitionsProcessor.read(DefinitionsProcessor.java:102) at org.apache.tuscany.sca.definitions.xml.DefinitionsProcessor.read(DefinitionsProcessor.java:62) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.read(DefaultStAXArtifactProcessorExtensionPoint.java:296) at org.apache.tuscany.sca.policy.wspolicy.WSPolicyTestCase.testReadWsPolicy(WSPolicyTestCase.java:166) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java
[jira] [Assigned] (TUSCANY-4043) Missing dependency issue with binding-comet-runtime causes a build failure
[ https://issues.apache.org/jira/browse/TUSCANY-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-4043: -- Assignee: ant elder Missing dependency issue with binding-comet-runtime causes a build failure -- Key: TUSCANY-4043 URL: https://issues.apache.org/jira/browse/TUSCANY-4043 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: IBM JDK (x86-64) Reporter: Andrew Potter Assignee: ant elder Priority: Blocker add to trunk\modules\binding-comet-runtime\pom.xml dependencies: dependency groupIdorg.slf4j/groupId artifactIdslf4j-log4j12/artifactId version1.6.1/version scopetest/scope /dependency -- 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-4043) Missing dependency issue with binding-comet-runtime causes a build failure
[ https://issues.apache.org/jira/browse/TUSCANY-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4043. -- Resolution: Fixed Thanks Andrew, fix applied. Missing dependency issue with binding-comet-runtime causes a build failure -- Key: TUSCANY-4043 URL: https://issues.apache.org/jira/browse/TUSCANY-4043 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.x Environment: IBM JDK (x86-64) Reporter: Andrew Potter Assignee: ant elder Priority: Blocker add to trunk\modules\binding-comet-runtime\pom.xml dependencies: dependency groupIdorg.slf4j/groupId artifactIdslf4j-log4j12/artifactId version1.6.1/version scopetest/scope /dependency -- 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: Publishing 2.0-Beta4 RC1, was Re: [RESULT][VOTE] Release 2.0-Beta4 RC1
On Tue, May 15, 2012 at 3:58 AM, Luciano Resende luckbr1...@gmail.com wrote: On Fri, Mar 16, 2012 at 1:44 AM, ant elder ant.el...@gmail.com wrote: Passed with four +1 votes from Luciano, Nirmal, Raymond and me. ...ant On Thu, Mar 8, 2012 at 9: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 I noticed that http://people.apache.org/~antelder/tuscany/2.0-Beta4-RC1/ has been moved. Ant, are you planning to publish this while we wait for 2.0 ? Otherwise, would you give me permission to copy it from your folder at p.a.o and working on publishing it ? As you know we said we'd instead go to 2.0, those artifacts are months old now and i've cleaned the RC from my p.a.o space. Why not just review and vote on 2.0? ...ant
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Thu, May 10, 2012 at 6:31 PM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:44 AM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:28 AM, Simon Laws simonsl...@googlemail.com wrote: ..snip Simon, It looks like you've not included the staging repo, the samples aren't finding the 2.0 pom's in Maven central because the release hasn't been published yet. doh - I'm getting out of practice. I'll try again. I can add a sentence to the top sample README saying what it is but what else if anything needs updating before doing a respin just for that? ...ant I'd like to run through the samples before a respin. Won't get to it until this evening. Simon I have just came back from vacation end of last week and I'm finally getting time to go over this and will send feedback soonish. On a related topic, would you guys be ok on waiting for finishing up Wink 1.2 release which a initial RC was done over the weekend, so that we can have it as part of the 2.0 release ? Ok, Wink 1.2 has been trough the voting process. I'll publish the artifacts and update Tuscany. Ok i see you've done that now, I could spin a new RC but there hasn't been much review of RC1 yet and there are still a bunch of issues that Simon raised (i've fixed all the getting started samples). Is anyone going to do any more reviews or fixes? ...ant
Re: Tuscany Board Report is due
Thats a little misleading about Beta4 and 2.0. The Beta4 release never happened and there's been no talk yet of a 2.0 RC2 and no commits towards that. I see the report is already submitted now so i guess i don't object too much but I probably would in future. ...ant On Tue, May 8, 2012 at 6:53 PM, Luciano Resende luckbr1...@gmail.com wrote: Looking into this quarter board report, and I see couple things to report - Tuscany 2.0 Beta4 release was approved, and the community is working on the RC2 of the official 2.0 release. - Tuscany community engaged with students as part of GSoC 2012, but the candidate had proposed ideas for multiple Apache projects and the Tuscany one was not selected. - The Tuscany PMC voted on a new policy on election and rotation of Project Chairs, and also recommended a new project Chair which got approved by the Board last month. Anything else that should be mentioned ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
[jira] [Closed] (TUSCANY-4037) OutOfMemoryError because domain registry holds remote endpoint references created by SCAClientFactory.getService
[ https://issues.apache.org/jira/browse/TUSCANY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4037. -- Resolution: Fixed Patch applied, thanks for the fix Greg. OutOfMemoryError because domain registry holds remote endpoint references created by SCAClientFactory.getService Key: TUSCANY-4037 URL: https://issues.apache.org/jira/browse/TUSCANY-4037 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Attachments: TUSCANY-4037-rev1.patch RuntimeEndpointReferenceImpl has the following code to add an endpoint reference to the domain registry. if (!getReference().getName().startsWith($self$.)) compositeContext.getEndpointRegistry().addEndpointReference(this); The check for a reference name starting with $self$ is intended to prevent references created by SCAClientFactory.getService() from being added to the registry. The check works fine for references to colocated services. However references to remote services start with a different string, $sca.client$. -- 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-4041) XSDModelResolver fails to resolve schema where location attribute is incorrect specified but schema may be available via artifact resolution.s
[ https://issues.apache.org/jira/browse/TUSCANY-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4041. -- Resolution: Fixed Patch applied, thanks for the fix Brian XSDModelResolver fails to resolve schema where location attribute is incorrect specified but schema may be available via artifact resolution.s -- Key: TUSCANY-4041 URL: https://issues.apache.org/jira/browse/TUSCANY-4041 Project: Tuscany Issue Type: Bug Components: Java SCA Databinding-SDO Affects Versions: Java-SCA-2.x Reporter: Brian Sullivan Attachments: XSDModelResolver.java.patch -- 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 Tuscany SCA 2.0 RC1
On Mon, Apr 30, 2012 at 12:28 PM, Simon Laws simonsl...@googlemail.com wrote: On Sat, Apr 28, 2012 at 9:57 AM, ant elder ant.el...@gmail.com wrote: Ok well thanks for looking. I think we all knew there were issues with some samples, and we saw what happened with the beta1 release when we tried to sort all that out and it descended into unconstructiveness. I can fix some of those that you've pointed out, though i wont have much time for a little while, but there are some i'm not interested in. I'd have preferred to just release what we have quickly and fix things incrementally in more frequent releases but for now i'll wait a little while and see if we get any fixes made and then look at an RC2 in a week or two. ...ant Ok, well for a 2.0 release I think we should either fix or remove stuff that doesn't work. I'll have some time but it's a bit sporadic at the moment. Ok I'll look forward to you sporadic help. I will point out that we tried the approach you suggest with Beta2 and had a 100+ email grumpy thread when people didn't like samples getting taken out. With the help we have IMHO its better to get a release out soon than sit on it for months or years as its not perfect and this is the approach I'm going to take with the next RCs. ...ant
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Tue, May 1, 2012 at 1:35 PM, Simon Nash n...@apache.org wrote: ant elder wrote: On Mon, Apr 30, 2012 at 12:28 PM, Simon Laws simonsl...@googlemail.com wrote: On Sat, Apr 28, 2012 at 9:57 AM, ant elder ant.el...@gmail.com wrote: Ok well thanks for looking. I think we all knew there were issues with some samples, and we saw what happened with the beta1 release when we tried to sort all that out and it descended into unconstructiveness. I can fix some of those that you've pointed out, though i wont have much time for a little while, but there are some i'm not interested in. I'd have preferred to just release what we have quickly and fix things incrementally in more frequent releases but for now i'll wait a little while and see if we get any fixes made and then look at an RC2 in a week or two. ...ant Ok, well for a 2.0 release I think we should either fix or remove stuff that doesn't work. I'll have some time but it's a bit sporadic at the moment. Ok I'll look forward to you sporadic help. I will point out that we tried the approach you suggest with Beta2 and had a 100+ email grumpy thread when people didn't like samples getting taken out. With the help we have IMHO its better to get a release out soon than sit on it for months or years as its not perfect and this is the approach I'm going to take with the next RCs. ...ant IIRC, there was agreement on that thread that samples that don't work should be taken out, but there were objections to removing samples that do work. Simon Hi Simon, I don't think there was ever real agreement with everyone on doing that, and before that there was agreement to move all the samples out and only move them back when working but it turned out that people didn't express their disagreement till after that worked actually started, and in either case I don't think there was ever real agreement on what working actually meant. What ever might have been agreed in the past I'm not sure that moving something that isn't perfect out now would actually help speed up getting the release out because when it actually comes down to it if someone finds their favorite sample isn't in an RC that they're reviewing it usually means they want a respin to put it back in. I think we'll just need to fix up enough to get three people happy enough to vote and what the work entails is going to depend on who those three voters are and as we don't have three yet i guess this is going to drag on. ...ant
Re: [VOTE] Release Tuscany SCA 2.0 RC1
Ok well thanks for looking. I think we all knew there were issues with
some samples, and we saw what happened with the beta1 release when we
tried to sort all that out and it descended into unconstructiveness. I
can fix some of those that you've pointed out, though i wont have much
time for a little while, but there are some i'm not interested in. I'd
have preferred to just release what we have quickly and fix things
incrementally in more frequent releases but for now i'll wait a little
while and see if we get any fixes made and then look at an RC2 in a
week or two.
...ant
On Thu, Apr 26, 2012 at 10:00 PM, Simon Laws simonsl...@googlemail.com wrote:
On Wed, Apr 25, 2012 at 9:32 PM, Simon Laws simonsl...@googlemail.com wrote:
snip...
Simon, It looks like you've not included the staging repo, the samples
aren't finding the 2.0 pom's in Maven central because the release
hasn't been published yet.
I've put the staging repo configuration in and am still having
problems. Can you paste you settings.xml configuration.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
I find an old version of settings.xml on a backup disc I have. I have
the config of the mirrors tag correct now and have made more progress.
Not quite done but here's what I've found in case someone has some
time
tuscany--distribution-all-2.0-src.zip - Fail - see [6]
tuscany-distribution-all-2.0.zip - TODO
tuscany-samples-2.0.zip
README - empty
CHANGES RELEASE_NOTES - should they be samples specific?
applications
store - Fail - see [3]
getting-started
getting-started.pdf - OK
helloworld - OK
helloworld-ant - README same as helloworld. Not sure what
it's supposed to do
helloworld-bpel - README talks about this being a Spring example.
helloworld-jaxrs - OK
helloworld-jsonp - OK
helloworld-jsonrpc - OK
helloworld-scaclient - Fail - see [1]
helloworld-spring - OK
helloworld-webapp - OK
helloworld-webservice - OK
helloworld-withdeps - Fail - see [2]
learning-more - No doc at this level
async-invocation - No doc. Fails when run - see [4]
binding-comet
binding-websocket
contribution-osgi
distributed-osgi-dynamic
distributed-osgi-static
running-tuscany
running-tuscany.html - Should be PDF for match getting started
ant - Fail - see [5]
README.html - PDF or text file?
command-line - OK
README.html - PDF or text file?
eclipse - OK
README.html - PDF or text file?
jse
junit
osgi
README.html - PDF or text file?
tuscany-war-2.0.war - TODO
Maven staging repo - OK
RAT - TODO
Signatures - TODO
[1]
C:\simon\sca\release\tuscany-samples-2.0\tuscany-samples-2.0\getting-started\hel
loworld-scaclientmvn tuscany:run
[INFO] Scanning for projects...
[INFO]
[INFO] Building Apache Tuscany SCA Samples Helloworld SCAClient
[INFO] task-segment: [tuscany:run]
[INFO]
[INFO] Preparing tuscany:run
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus
.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 2 source files to
C:\simon\sca\release\tuscany-samples-2.0\tusc
any-samples-2.0\getting-started\helloworld-scaclient\target\classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\simon\sca\release\tuscany-samples-
2.0\tuscany-samples-2.0\getting-started\helloworld-scaclient\src\test\resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 1 source file to
C:\simon\sca\release\tuscany-samples-2.0\tusca
ny-samples-2.0\getting-started\helloworld-scaclient\target\test-classes
[INFO] [tuscany:run {execution: default-cli}]
[INFO] Invoking sample.HelloworldSCAClient class main method...
HelloworldSCAClient, using domainURI
Re: [VOTE] Release Tuscany SCA 2.0 RC1
Still looking for votes. Its been nearly two weeks now... ...ant On Thu, Apr 12, 2012 at 6:04 PM, ant elder ant.el...@gmail.com wrote: I've spun the artifacts for the 2.0 release, they're available at: http://people.apache.org/~antelder/tuscany/2.0-RC1/ Please review and cast your vote on releasing. Many thanks, ...ant
Re: [VOTE] Release Tuscany SCA 2.0 RC1
Looks ok to me so +1. ...ant On Thu, Apr 12, 2012 at 6:04 PM, ant elder ant.el...@gmail.com wrote: I've spun the artifacts for the 2.0 release, they're available at: http://people.apache.org/~antelder/tuscany/2.0-RC1/ Please review and cast your vote on releasing. Many thanks, ...ant
Re: Releasing Maven Artifacts
(Great to save that query till after the vote was posted...) I don't recall that happening and believe it still works ok, could you be mixing it up with the svn pubsub changes for websites? Do you have any links to emails? Anyway I don't think this should interfere with the current vote as the Maven jars could be redeployed or manually put into nexus and released from there so either way it should be ok. ...ant On Thu, Apr 12, 2012 at 8:09 PM, Luciano Resende luckbr1...@gmail.com wrote: I think I remember seeing an e-mail from Infra that they were going to discontinue support for the maven rsync release folder and force all projects to use Nexus. Is that correct ? Would that have any side effects on our 2.0 release candidate ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
[VOTE] Release Tuscany SCA 2.0 RC1
I've spun the artifacts for the 2.0 release, they're available at: http://people.apache.org/~antelder/tuscany/2.0-RC1/ Please review and cast your vote on releasing. Many thanks, ...ant
Re: [RESULT][VOTE] Release 2.0-Beta4 RC1
On Sun, Apr 1, 2012 at 9:56 AM, Luciano Resende luckbr1...@gmail.com wrote: On Sun, Apr 1, 2012 at 1:36 AM, ant elder ant.el...@gmail.com wrote: On Fri, Mar 30, 2012 at 7:59 AM, ant elder ant.el...@gmail.com wrote: On Wed, Mar 28, 2012 at 9:54 PM, Luciano Resende luckbr1...@gmail.com wrote: On Fri, Mar 16, 2012 at 1:44 AM, ant elder ant.el...@gmail.com wrote: Passed with four +1 votes from Luciano, Nirmal, Raymond and me. ...ant On Thu, Mar 8, 2012 at 9: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 Did we ever finish this release and sent announcements ? I can't see the e-mail on my archive, and site still pointing to previous release. No. I'm a bit busy right now and not so motivated to spend my free time on Tuscany after last weeks spat. I will get this done but if anyone else wants to help publish the artifacts or update the website before then go for it. ...ant What say we respin this naming it 2.0? ...ant I'd probably would like to do a double check on the samples if we officially call it 2.0. But otherwise seems like a overdue good idea. Hows the sample checking going? And anyone else any concerns with doing this? If no more comments i'll do an RC1 in a few days. ...ant
Re: [RESULT][VOTE] Release 2.0-Beta4 RC1
On Fri, Mar 30, 2012 at 7:59 AM, ant elder ant.el...@gmail.com wrote: On Wed, Mar 28, 2012 at 9:54 PM, Luciano Resende luckbr1...@gmail.com wrote: On Fri, Mar 16, 2012 at 1:44 AM, ant elder ant.el...@gmail.com wrote: Passed with four +1 votes from Luciano, Nirmal, Raymond and me. ...ant On Thu, Mar 8, 2012 at 9: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 Did we ever finish this release and sent announcements ? I can't see the e-mail on my archive, and site still pointing to previous release. No. I'm a bit busy right now and not so motivated to spend my free time on Tuscany after last weeks spat. I will get this done but if anyone else wants to help publish the artifacts or update the website before then go for it. ...ant What say we respin this naming it 2.0? ...ant
Re: [RESULT][VOTE] Release 2.0-Beta4 RC1
On Wed, Mar 28, 2012 at 9:54 PM, Luciano Resende luckbr1...@gmail.com wrote: On Fri, Mar 16, 2012 at 1:44 AM, ant elder ant.el...@gmail.com wrote: Passed with four +1 votes from Luciano, Nirmal, Raymond and me. ...ant On Thu, Mar 8, 2012 at 9: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 Did we ever finish this release and sent announcements ? I can't see the e-mail on my archive, and site still pointing to previous release. No. I'm a bit busy right now and not so motivated to spend my free time on Tuscany after last weeks spat. I will get this done but if anyone else wants to help publish the artifacts or update the website before then go for it. ...ant
[jira] [Commented] (TUSCANY-4029) Binding object inadvertently shared across Endpoint and EndpointReference causes errors
[ https://issues.apache.org/jira/browse/TUSCANY-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235449#comment-13235449 ] ant elder commented on TUSCANY-4029: Hi Raymond, I've had a look at the RESTBindingInvoker code and i think thats actually where the bug is. Rather than relying on the Binding objects getting shared across service and reference RESTBindingInvoker should be using endpointReference.getTargetEndpoint().getBinding().getURI() to get the URI of the deployed service. That approach will work regardless of whether or not the same instance is shared and it will work with Tuscany's dynamic and distributed domain. Binding object inadvertently shared across Endpoint and EndpointReference causes errors --- Key: TUSCANY-4029 URL: https://issues.apache.org/jira/browse/TUSCANY-4029 Project: Tuscany Issue Type: Bug Reporter: ant elder The Binding object stored in the EndpointReference is the same object as stored in the Endpoint which can cause obscure errors when setting attributes on the service also effects the reference and vica versa. -- 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: svn commit: r1303591 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
On Wed, Mar 21, 2012 at 9:49 PM, rf...@apache.org wrote:
Author: rfeng
Date: Wed Mar 21 21:49:52 2012
New Revision: 1303591
URL: http://svn.apache.org/viewvc?rev=1303591view=rev
Log:
Revert the change based on the comment from
https://issues.apache.org/jira/browse/TUSCANY-4029
Modified:
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Modified:
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
URL:
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java?rev=1303591r1=1303590r2=1303591view=diff
==
---
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
(original)
+++
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Wed Mar 21 21:49:52 2012
@@ -338,6 +338,11 @@ public class EndpointReferenceBinderImpl
}
+ // [rfeng] Setup the target endpoint if the reference uses an
explicit binding
+ if (endpointReference.getTargetEndpoint().getBinding() == null) {
+
endpointReference.getTargetEndpoint().setBinding(endpointReference.getBinding());
+ }
+
// Now the endpoint reference is resolved check that the binding
interfaces contract
// and the reference contract are compatible
try {
@@ -500,12 +505,16 @@ public class EndpointReferenceBinderImpl
} else {
endpointReference.setTargetEndpoint(matchedEndpoint);
Binding binding = matchedEndpoint.getBinding();
+ // Reverted the change, see
https://issues.apache.org/jira/browse/TUSCANY-4029
+ /*
try {
endpointReference.setBinding((Binding)
binding.clone());
} catch (CloneNotSupportedException e) {
// shouldn't happen
throw new RuntimeException(e);
}
+ */
+ endpointReference.setBinding(binding);
// TUSCANY-3873 - add policy from the service
// we don't care about intents at this stage
endpointReference.getPolicySets().addAll(matchedEndpoint.getPolicySets());
@@ -528,6 +537,7 @@ public class EndpointReferenceBinderImpl
endpointReference.setStatus(EndpointReference.Status.WIRED_TARGET_FOUND_AND_MATCHED);
endpointReference.setUnresolved(false);
}
+
}
private void build(EndpointReference endpointReference) {
Raymond, as discussed in TUSCANY-4029 and on the IM chat we had
yesterday i'm -1 on your commit. It doesn't fix the problem which
TUSCANY-4029 addresses and it also breaks the OASIS compliance tests.
If there are any issues with the approach suggested in TUSCANY-4029
then lets discuss it here or you're welcome to IM ping me to more
quickly find a solution that works for everyone.
...ant
Re: svn commit: r1302317 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
On Wed, Mar 21, 2012 at 10:35 PM, Luciano Resende luckbr1...@gmail.com wrote: On Wed, Mar 21, 2012 at 2:57 PM, ant elder ant.el...@gmail.com wrote: On Wed, Mar 21, 2012 at 9:48 PM, Raymond Feng enjoyj...@gmail.com wrote: Hi, The change had a huge impact on all the binding invokers that rely on the service binding to resolve the deployed URIs when the endpoint reference is resolved to a target endpoint. BTW, the use case applies to something like the following: component name=A service name=S1 tuscany:binding.rest uri=/a/b/ /service /component component name=B reference name=r1 target=A/S1/ /component The r1 reference is now have /a/b as the uri instead of the deployed URI. Ideally, the binding invoker should ask for the target endpoint's deployed URI. But it involves quite a bit changes. I'll revert the change for now until we find a consistent solution. Raymond, I think you know that unilaterally reverting a commit like that is not the way to do things. ...ant I don't see this as unilaterally reverting a commit. I see this as a commit extensively broke existing functionality, the issue was brought up in the mailing list for discussion of a better fix, while, in the mean time, the commit was reverted. Please let's concentrate on the technical facts and try to find a solution that works without huge impact on existing functionality. Luciano, the build didn't get broken until the r1303591 commit so phrases like extensively broke do nothing to constructively help find a solution that works for everyone. There is well known and clear ASF process for vetos and following that will help avoid these type of exchanges. From whats been said so far about this issue it seems like the rest binding invoker has no tests for this function and was only working by relying on an existing bug so having that change while we clean up trunk on the way to 2.0 is no cause for getting grumpy. There has already been a fix for that suggested in TUSCANY-4029, if that doesn't completely resolve the issue then respectful dev in trunk and dev-list is the way to get to something that does. ...ant
Re: svn commit: r1303591 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
On Thu, Mar 22, 2012 at 2:46 PM, Luciano Resende luckbr1...@gmail.com wrote:
On Thursday, March 22, 2012, ant elder ant.el...@gmail.com wrote:
On Wed, Mar 21, 2012 at 9:49 PM, rf...@apache.org wrote:
Author: rfeng
Date: Wed Mar 21 21:49:52 2012
New Revision: 1303591
URL: http://svn.apache.org/viewvc?rev=1303591view=rev
Log:
Revert the change based on the comment from
https://issues.apache.org/jira/browse/TUSCANY-4029
Modified:
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Modified:
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
URL:
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java?rev=1303591r1=1303590r2=1303591view=diff
==
---
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
(original)
+++
tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Wed Mar 21 21:49:52 2012
@@ -338,6 +338,11 @@ public class EndpointReferenceBinderImpl
}
+ // [rfeng] Setup the target endpoint if the reference uses an
explicit binding
+ if (endpointReference.getTargetEndpoint().getBinding() == null)
{
+
endpointReference.getTargetEndpoint().setBinding(endpointReference.getBinding());
+ }
+
// Now the endpoint reference is resolved check that the binding
interfaces contract
// and the reference contract are compatible
try {
@@ -500,12 +505,16 @@ public class EndpointReferenceBinderImpl
} else {
endpointReference.setTargetEndpoint(matchedEndpoint);
Binding binding = matchedEndpoint.getBinding();
+ // Reverted the change, see
https://issues.apache.org/jira/browse/TUSCANY-4029
+ /*
try {
endpointReference.setBinding((Binding)
binding.clone());
} catch (CloneNotSupportedException e) {
// shouldn't happen
throw new RuntimeException(e);
}
+ */
+ endpointReference.setBinding(binding);
// TUSCANY-3873 - add policy from the service
// we don't care about intents at this stage
endpointReference.getPolicySets().addAll(matchedEndpoint.getPolicySets());
@@ -528,6 +537,7 @@ public class EndpointReferenceBinderImpl
endpointReference.setStatus(EndpointReference.Status.WIRED_TARGET_FOUND_AND_MATCHED);
Raymond, as discussed in TUSCANY-4029 and on the IM chat we had
yesterday i'm -1 on your commit. It doesn't fix the problem which
TUSCANY-4029 addresses and it also breaks the OASIS compliance tests.
If there are any issues with the approach suggested in TUSCANY-4029
then lets discuss it here or you're welcome to IM ping me to more
quickly find a solution that works for everyone.
...ant
Please, let's keep these technical discussions on the mailing list.
BTW, how come it breakes the compliance test ? It has been like this forever
and the tests were passing fine.
In the same way, your fix seems to break other stuff as well as commented on
the other thread, which I'm -1 on having all that broken.
Can you provide more details about what other stuff is broken? The
build works, does the update suggested in TUSCANY-4029 fix the problem
with the rest invoker?
...ant
Re: svn commit: r1303591 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Come on Raymond if anyone is playing games it is you by reverting changes, comments inline below: ...ant On Thu, Mar 22, 2012 at 4:38 PM, Raymond Feng enjoyj...@gmail.com wrote: Ant, please STOP playing the veto game here. 1. Your change broke most if not all the binding invokers that make outbound connections using the binding uri even though the failures were not directly exposed due to lack of test coverage which we should improve. The change did not break the Tuscany build, or any tests. If you have a particular use case that is not part of that you should add some tests to Tuscany for it. At the very least you should be less upset when a trunk change impacts your non-tested use cases while you don't have tests for them in the build. 2. The Endpoint concept was introduced later in the cycle. As a result, most of the reference binding invokers still depend on the behavior that the reference binding is set with the deployed service endpoint uri. We can argue if it's good or bad but we need to fix them before another bug fix regressed the code so much. I will try to fix the binding invokers but it will take a bit time. Ok finally that gives a hint at what your issue is - so are you agreeing now that the Rest invoker just hasn't kept up with trunk dev and now has a bug that needs fixing along the lines of what i've suggested in TUSCANY-4029? 3. I have the same veto right too. The only thing is that my revert didn't completely roll back all your changes including the failing compliance test if it's added recently. I explained in the e-mail why I need to revert your change. Maybe I should say -1 or veto your change too to make it clear. Yes you could, but you need a technical reason to support it and then you leave the actual reverting to be done by the person you're vetoing. And the technical reason for this objection here is seeming very hard to get you or Luciano to actually give precise details on. And BTW, the compliance test thats now broken is not a new one its been there for ages, even if it was new thats shouldn't make a difference - trunk is where we do new development. 4. Please don't abuse/stain the Apache hat when/if you try to push for some 'private' agenda. Sorry for being harsh here but otherwise we'll be painted as anti-Apache if we have technical disagreement. I don't know about anti-Apache but it doesn't feel particularly community spirited with this aggressive over reaction that i'm getting from you and Luciano for a change that didn't even break anything within Tuscany. If we're ever going to encourage others to come participate in development here, especially as volunteers in their own time, we need to have a more friendly approach when you don't like or understand something. ...ant
Re: svn commit: r1303591 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
Come on Raymond be a bit nice. The Web Service binding worked, there are tests that uses it with @target, the Hazelcast binding too. Whether or not its actually possible with the protocol i doubt anyone would ever use the jsonp binding like that as it makes no sense, atom is likely similar, and i doubt there are many real world use cases where JMS would be used like that either as the client and service ends usually would need quite different configuration. So they don't ALL need updating. In fact i vaguely remember when @target came up for discussion on the ML in the past there were some strong arguments made for only supporting it with binding.sca anyway. And presently there is nothing to change as you've reverted the update, if you're agreeing to put it back I'm happy to help make any other updates. ...ant On Thu, Mar 22, 2012 at 5:56 PM, Raymond Feng enjoyj...@gmail.com wrote: I'm making one final clarification before wasting more time: As I pointed out, the break you introduced applied to most if not all reference binding invokers. Please don't try to hint it's only RESTBindingInvoker. Now I'll go to fix ALL reference binding invokers. Raymond Feng Sent from my iPhone On Mar 22, 2012, at 10:11 AM, ant elder ant.el...@gmail.com wrote: Come on Raymond if anyone is playing games it is you by reverting changes, comments inline below: ...ant On Thu, Mar 22, 2012 at 4:38 PM, Raymond Feng enjoyj...@gmail.com wrote: Ant, please STOP playing the veto game here. 1. Your change broke most if not all the binding invokers that make outbound connections using the binding uri even though the failures were not directly exposed due to lack of test coverage which we should improve. The change did not break the Tuscany build, or any tests. If you have a particular use case that is not part of that you should add some tests to Tuscany for it. At the very least you should be less upset when a trunk change impacts your non-tested use cases while you don't have tests for them in the build. 2. The Endpoint concept was introduced later in the cycle. As a result, most of the reference binding invokers still depend on the behavior that the reference binding is set with the deployed service endpoint uri. We can argue if it's good or bad but we need to fix them before another bug fix regressed the code so much. I will try to fix the binding invokers but it will take a bit time. Ok finally that gives a hint at what your issue is - so are you agreeing now that the Rest invoker just hasn't kept up with trunk dev and now has a bug that needs fixing along the lines of what i've suggested in TUSCANY-4029? 3. I have the same veto right too. The only thing is that my revert didn't completely roll back all your changes including the failing compliance test if it's added recently. I explained in the e-mail why I need to revert your change. Maybe I should say -1 or veto your change too to make it clear. Yes you could, but you need a technical reason to support it and then you leave the actual reverting to be done by the person you're vetoing. And the technical reason for this objection here is seeming very hard to get you or Luciano to actually give precise details on. And BTW, the compliance test thats now broken is not a new one its been there for ages, even if it was new thats shouldn't make a difference - trunk is where we do new development. 4. Please don't abuse/stain the Apache hat when/if you try to push for some 'private' agenda. Sorry for being harsh here but otherwise we'll be painted as anti-Apache if we have technical disagreement. I don't know about anti-Apache but it doesn't feel particularly community spirited with this aggressive over reaction that i'm getting from you and Luciano for a change that didn't even break anything within Tuscany. If we're ever going to encourage others to come participate in development here, especially as volunteers in their own time, we need to have a more friendly approach when you don't like or understand something. ...ant
[jira] [Closed] (TUSCANY-4024) wireFormat element written in wrong place in the binding.jms response element
[ https://issues.apache.org/jira/browse/TUSCANY-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4024. -- Resolution: Fixed Should be fixed now. wireFormat element written in wrong place in the binding.jms response element - Key: TUSCANY-4024 URL: https://issues.apache.org/jira/browse/TUSCANY-4024 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.0 Environment: All OS Reporter: Vijai Kalathur Assignee: ant elder If I start out with a component like this service name=InvokeServiceOasis binding.jms tuscany:wireFormat.jmsObject/ activationSpec create=never jndiName=jms/Oasis_JMS_AS/ response destination create=never jndiName=jms/Oasis_JMS_Response type=queue/ connectionFactory create=never jndiName=jms/Oasis_JMS_CF/ /response /binding.jms /service after it goes through the composite build process, the resulting component looks like this: service name=InvokeServiceOasis binding.jms tuscany:wireFormat.jmsObject/ activationSpec create=never jndiName=jms/Oasis_JMS_AS/ response destination create=never jndiName=jms/Oasis_JMS_Response type=queue/ connectionFactory create=never jndiName=jms/Oasis_JMS_CF/ tuscany:wireFormat.jmsObject/ /response /binding.jms /service I am not sure if there is a reason why we need to write tuscany:wireFormat.jmsObject/ into the response element and if we do need to include it for some reason, it should be the first element under the response. This causes a validation failure currently. -- 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: svn commit: r1302317 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
On Wed, Mar 21, 2012 at 9:01 PM, Raymond Feng enjoyj...@gmail.com wrote: Hi, This change breaks the case where we use @target in the reference element to wire components using non-SCA bindings. For example, the RESTBindingInvoker uses the binding.uri to find out the target address. Since now it's a clone, the value won't be updated when the service binding set the deployed URI. A better fix is to retrieve the deployed URI from the target endpoint. I agree its irksome that simple local @target references can't rely on getting the service url set after its wired up but really that seems like it was only working previously by relying on the bug that the objects were shared. Getting the URI from the target endpoint isn't going to solve all the other problems that can happen when the Binding object is shared, the problem is that what information within a Binding can or can't be shared between the Endpoint and EndpointReference is difficult to determine and varies across binding impls - policy, databindings, really any of the binding fields - getting set by one side can easily overwrite what the other end had previously set. I can't yet see a better way to fix this than cloning the binding here. What about trying to fix the deployed service URI getting passed on to the reference by doing something with the EndpointRegistry so that setting the deployed URI on the service Endpoint in there gets its replicated to the reference side? ...ant
Re: svn commit: r1302317 - /tuscany/sca-java-2.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/runtime/impl/EndpointReferenceBinderImpl.java
On Wed, Mar 21, 2012 at 9:48 PM, Raymond Feng enjoyj...@gmail.com wrote: Hi, The change had a huge impact on all the binding invokers that rely on the service binding to resolve the deployed URIs when the endpoint reference is resolved to a target endpoint. BTW, the use case applies to something like the following: component name=A service name=S1 tuscany:binding.rest uri=/a/b/ /service /component component name=B reference name=r1 target=A/S1/ /component The r1 reference is now have /a/b as the uri instead of the deployed URI. Ideally, the binding invoker should ask for the target endpoint's deployed URI. But it involves quite a bit changes. I'll revert the change for now until we find a consistent solution. Raymond, I think you know that unilaterally reverting a commit like that is not the way to do things. ...ant
[jira] [Commented] (TUSCANY-4024) wireFormat element written in wrong place in the binding.jms response element
[ https://issues.apache.org/jira/browse/TUSCANY-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232631#comment-13232631 ] ant elder commented on TUSCANY-4024: I've fixed the place where the wireFormat elements get written so that the scdl doesn't get validation failures. I can't recreate the issue with the wireFormat.jmsObject getting written when it wasn't there in the original SCDL so i wonder if that is coming from somewhere else outside of Tuscany? Can you give any more info on how to recreate the problem? wireFormat element written in wrong place in the binding.jms response element - Key: TUSCANY-4024 URL: https://issues.apache.org/jira/browse/TUSCANY-4024 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.0 Environment: All OS Reporter: Vijai Kalathur Assignee: ant elder If I start out with a component like this service name=InvokeServiceOasis binding.jms tuscany:wireFormat.jmsObject/ activationSpec create=never jndiName=jms/Oasis_JMS_AS/ response destination create=never jndiName=jms/Oasis_JMS_Response type=queue/ connectionFactory create=never jndiName=jms/Oasis_JMS_CF/ /response /binding.jms /service after it goes through the composite build process, the resulting component looks like this: service name=InvokeServiceOasis binding.jms tuscany:wireFormat.jmsObject/ activationSpec create=never jndiName=jms/Oasis_JMS_AS/ response destination create=never jndiName=jms/Oasis_JMS_Response type=queue/ connectionFactory create=never jndiName=jms/Oasis_JMS_CF/ tuscany:wireFormat.jmsObject/ /response /binding.jms /service I am not sure if there is a reason why we need to write tuscany:wireFormat.jmsObject/ into the response element and if we do need to include it for some reason, it should be the first element under the response. This causes a validation failure currently. -- 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-4029) Binding object inadvertently shared across Endpoint and EndpointReference causes errors
Binding object inadvertently shared across Endpoint and EndpointReference causes errors --- Key: TUSCANY-4029 URL: https://issues.apache.org/jira/browse/TUSCANY-4029 Project: Tuscany Issue Type: Bug Reporter: ant elder The Binding object stored in the EndpointReference is the same object as stored in the Endpoint which can cause obscure errors when setting attributes on the service also effects the reference and vica versa. -- 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
[RESULT][VOTE] Release 2.0-Beta4 RC1
Passed with four +1 votes from Luciano, Nirmal, Raymond and me. ...ant On Thu, Mar 8, 2012 at 9: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
Re: [VOTE] Release 2.0-Beta4 RC1
Still looking for votes on this, one more is needed to release...anyone? ...ant On Mon, Mar 12, 2012 at 8:40 AM, ant elder ant.el...@gmail.com wrote: 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
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
Re: [VOTE] Release 2.0-Beta4 RC1
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
[VOTE] Release 2.0-Beta4 RC1
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
[jira] [Assigned] (TUSCANY-4024) wireFormat element written in wrong place in the binding.jms response element
[ https://issues.apache.org/jira/browse/TUSCANY-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-4024: -- Assignee: ant elder wireFormat element written in wrong place in the binding.jms response element - Key: TUSCANY-4024 URL: https://issues.apache.org/jira/browse/TUSCANY-4024 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.0 Environment: All OS Reporter: Vijai Kalathur Assignee: ant elder If I start out with a component like this service name=InvokeServiceOasis binding.jms tuscany:wireFormat.jmsObject/ activationSpec create=never jndiName=jms/Oasis_JMS_AS/ response destination create=never jndiName=jms/Oasis_JMS_Response type=queue/ connectionFactory create=never jndiName=jms/Oasis_JMS_CF/ /response /binding.jms /service after it goes through the composite build process, the resulting component looks like this: service name=InvokeServiceOasis binding.jms tuscany:wireFormat.jmsObject/ activationSpec create=never jndiName=jms/Oasis_JMS_AS/ response destination create=never jndiName=jms/Oasis_JMS_Response type=queue/ connectionFactory create=never jndiName=jms/Oasis_JMS_CF/ tuscany:wireFormat.jmsObject/ /response /binding.jms /service I am not sure if there is a reason why we need to write tuscany:wireFormat.jmsObject/ into the response element and if we do need to include it for some reason, it should be the first element under the response. This causes a validation failure currently. -- 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: Another 2.x beta release
Did anyone have a look at this or have any updates before i cut an RC1? There are still a bunch of issues with things like the samples, but no more so than was released in the last release so i'd like to ignore them for now and get this release out as is, any objections to that? ...ant On Thu, Feb 9, 2012 at 1:05 PM, ant elder antel...@apache.org wrote: I've done a little clean up to the point where a release tag would build and tag that and spun the release artifacts so we can see what they look like at present. They're up at: http://people.apache.org/~antelder/tuscany/2.0-Beta4-review/ I haven't created a branch, for the time being we can do the release prep in trunk i think. ...ant
Re: Another 2.x beta release
On Thu, Feb 9, 2012 at 11:50 PM, Luciano Resende luckbr1...@gmail.com wrote: If I don't get them done by sunday night, then i don't want to hold this ... Turns out the internet where i am is slow and flaky and I'm not making fast progress on this so no one needs to worry about holding anything up for now. ...ant
Tuscany website
See the forwarded note below on changes to how Tuscany must manage the website. We've got until next year but it will probably take some time to sort out. Any volunteers to go have a look and see whats required? ...ant -- Forwarded message -- From: Joe Schaefer joe_schae...@yahoo.com Date: Wed, Feb 8, 2012 at 12:26 PM Subject: Mandatory svnpubsub migration by Jan 2013 To: Apache Infrastructure infrastruct...@apache.org [PLEASE DO NOT RESPOND TO THIS POST! DIRECT ALL FURTHER INQUIRIES TO infrastruct...@apache.org] FYI: infrastructure policy regarding website hosting has changed as of November 2011: we are requiring all websites and dist/ dirs to be svnpubsub or ASF CMS backed by the end of 2012. If your PMC has already met this requirement congratulations, you can ignore the remainder of this post. As stated on http://www.apache.org/dev/project-site.html#svnpubsub we are migrating our webserver infrastructure to 100% svnpubsub over the course of 2012. If your site does not currently make use of this technology, it is time to consider a migration effort, as rsync-based sites will be PERMANENTLY FROZEN in Jan 2013 due to infra disabling the hourly rsync jobs. While we recommend migrating to the ASF CMS [0] for Anakia based or Confluence based sites, and have provided tooling [1] to help facilitate this, we are only mandating svnpubsub (which the CMS uses itself). svnpubsub is a client-server system whereby a client watches an svn working copy for relevant commit notifications from the svn server. It subsequently runs svn up on the working copy, bringing in the relevant changes. sites that use static build technologies that commit the build results to svn are naturally compatible with svnpubsub; simply file a JIRA ticket with INFRA to request a migration: any commits to the resulting build tree will be instantly picked up on the live site. The CMS is a more elaborate system based on svnpubsub which provides a webgui for convenient online editing. Dozens of sites have already successfully deployed using the CMS and are quite happy with the results. The system is sufficiently flexible to accommodate a wide variety of choices regarding templating systems and storage formats, but most sites have standardized on the combination of Django and Markdown. Talk to infra if you would like to use the CMS in this or some other fashion, we'll see what we can do. NOTE: the policy for dist/ dirs for managing project releases is similar. We have setup a dedicated svn server for handling this, please contact infra when you are ready to start using it. HTH [0]: http://www.apache.org/dev/cms [1]: https://svn.apache.org/repos/infra/websites/cms/conversion-utilities/
Re: Another 2.x beta release
I've done a little clean up to the point where a release tag would build and tag that and spun the release artifacts so we can see what they look like at present. They're up at: http://people.apache.org/~antelder/tuscany/2.0-Beta4-review/ I haven't created a branch, for the time being we can do the release prep in trunk i think. ...ant
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
Another 2.x beta release
I'd like to get some of the 2.x changes since beta3 out in a release so am thinking about doing a beta4 release. Does anyone have anything coming up they would like the release to wait for, if not I'd like to start soon. I'm suggesting beta4 as I don't think the current trunk is quite ready for a 2.0 final and i expect it might take a little while to get it up to scratch and i'd like a new release sooner. I'd be happy to help start working towards the 2.0 release as well though if anyone else has time for that as well. ...ant
Re: Another 2.x beta release
On Mon, Feb 6, 2012 at 2:58 PM, Simon Laws simonsl...@googlemail.com wrote: On Mon, Feb 6, 2012 at 9:21 AM, ant elder ant.el...@gmail.com wrote: I'd like to get some of the 2.x changes since beta3 out in a release so am thinking about doing a beta4 release. Does anyone have anything coming up they would like the release to wait for, if not I'd like to start soon. I'm suggesting beta4 as I don't think the current trunk is quite ready for a 2.0 final and i expect it might take a little while to get it up to scratch and i'd like a new release sooner. I'd be happy to help start working towards the 2.0 release as well though if anyone else has time for that as well. ...ant Sounds good. It's been a long time since the last Beta and doing another one before 2.0 will give us a chance to get back into the swing of doing a release. Is this you offering to RM a beta4? Yes, though I'm not so keen on the RM label any more, especially so after some of the recent discussion on the Incubator mailing lists. Most releases are a team effort and build on the work of others. I will though be proactively trying to get it done but also happy to have anyone else help. ...ant
[NOTICE] Jennifer Thompson voted as a Tuscany Committer
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
[jira] [Assigned] (TUSCANY-4009) Java2 Secuity Errors in JMSMessageProcessorUtil
[ https://issues.apache.org/jira/browse/TUSCANY-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-4009: -- Assignee: ant elder Java2 Secuity Errors in JMSMessageProcessorUtil --- Key: TUSCANY-4009 URL: https://issues.apache.org/jira/browse/TUSCANY-4009 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: ant elder Fix For: Java-SCA-2.x Attachments: JMSMessageProcessorUtil-Java2Sec.patch When running with Java 2 security enabled th following error is encountered originating from JMSMessageProcessorUtil: Caused by: java.security.AccessControlException: Access denied (java.lang.RuntimePermission accessDeclaredMembers) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208) at java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1689) at java.lang.Class.checkMemberAccess(Class.java:107) at java.lang.Class.getDeclaredConstructor(Class.java:415) at org.apache.tuscany.sca.binding.jms.provider.JMSMessageProcessorUtil.instantiate(JMSMessageProcessorUtil.java:82) ... 70 more -- 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-4009) Java2 Secuity Errors in JMSMessageProcessorUtil
[ https://issues.apache.org/jira/browse/TUSCANY-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4009. -- Resolution: Fixed Patch applied, thanks for the fix Jennifer Java2 Secuity Errors in JMSMessageProcessorUtil --- Key: TUSCANY-4009 URL: https://issues.apache.org/jira/browse/TUSCANY-4009 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: ant elder Fix For: Java-SCA-2.x Attachments: JMSMessageProcessorUtil-Java2Sec.patch When running with Java 2 security enabled th following error is encountered originating from JMSMessageProcessorUtil: Caused by: java.security.AccessControlException: Access denied (java.lang.RuntimePermission accessDeclaredMembers) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208) at java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1689) at java.lang.Class.checkMemberAccess(Class.java:107) at java.lang.Class.getDeclaredConstructor(Class.java:415) at org.apache.tuscany.sca.binding.jms.provider.JMSMessageProcessorUtil.instantiate(JMSMessageProcessorUtil.java:82) ... 70 more -- 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: svn commit: r1228150 - in /tuscany/sca-java-2.x/trunk/modules: assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/ assembly-xml/src/test/java/org/apache/tuscany/sca/assembly/xml/ assem
On Fri, Jan 6, 2012 at 12:35 PM, sl...@apache.org wrote: Author: slaws Date: Fri Jan 6 12:35:01 2012 New Revision: 1228150 URL: http://svn.apache.org/viewvc?rev=1228150view=rev Log: TUSCANY-3932 - First part of this JIRA is to remove some inconsistencies in the way that callbacks are handled now. See JIRA for more comments on this first change. There are two JMS compliance tests failing now related to callbacks, and this change looks like a possible cause. Does that seem likely? ...ant
[jira] [Closed] (TUSCANY-4008) operationProperties selectedOperation element not selecting the correct operation
[ https://issues.apache.org/jira/browse/TUSCANY-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4008. -- Resolution: Fixed Patch applied, thanks for the fix Jennifer. I did also have to update the JMS selectors itest which was using this function so needed to be updated to match. operationProperties selectedOperation element not selecting the correct operation --- Key: TUSCANY-4008 URL: https://issues.apache.org/jira/browse/TUSCANY-4008 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: ant elder Fix For: Java-SCA-2.x Attachments: selectedOperation.patch Original Estimate: 1h Remaining Estimate: 1h the operationProperties selectedOperation element is not selecting the correct operation when specified in a .composite file. For example: operationProperties name=subtract selectedOperation=proxyOpName / Following the rules of operation selection, the operation selector determined the operation should be proxyOpName, but even though the opertionProperties element was specified to have subtract be invoked, the code actually invoked proxyOpName. Debugged revealed the code was recognizing that a native operation should be updated, but it was retrieving the wrong information. JMSBinding.nativeOperationNames map is essentially backwards from what we actually want to retrieve (it was retrieving the native operation rather than the opName). So I've created a patch which create a new table mapping native operation - opName, and updated the code as appropriate. -- 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] [Assigned] (TUSCANY-4008) operationProperties selectedOperation element not selecting the correct operation
[ https://issues.apache.org/jira/browse/TUSCANY-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-4008: -- Assignee: ant elder operationProperties selectedOperation element not selecting the correct operation --- Key: TUSCANY-4008 URL: https://issues.apache.org/jira/browse/TUSCANY-4008 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: ant elder Fix For: Java-SCA-2.x Attachments: selectedOperation.patch Original Estimate: 1h Remaining Estimate: 1h the operationProperties selectedOperation element is not selecting the correct operation when specified in a .composite file. For example: operationProperties name=subtract selectedOperation=proxyOpName / Following the rules of operation selection, the operation selector determined the operation should be proxyOpName, but even though the opertionProperties element was specified to have subtract be invoked, the code actually invoked proxyOpName. Debugged revealed the code was recognizing that a native operation should be updated, but it was retrieving the wrong information. JMSBinding.nativeOperationNames map is essentially backwards from what we actually want to retrieve (it was retrieving the native operation rather than the opName). So I've created a patch which create a new table mapping native operation - opName, and updated the code as appropriate. -- 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-4002) Updates to JMSBindingContext JMSBindingProcessor to allow for additional extensions.
[ https://issues.apache.org/jira/browse/TUSCANY-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4002. -- Resolution: Fixed Patches applied, thanks for the updates Jenniifer Updates to JMSBindingContext JMSBindingProcessor to allow for additional extensions. --- Key: TUSCANY-4002 URL: https://issues.apache.org/jira/browse/TUSCANY-4002 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Fix For: Java-SCA-2.x Attachments: JMSBindingContext.patch, JMSBindingProcessor-resolve.patch The following updates should be made to allow the JMS Binding to allow for additional extensions: 1) Add a HashTable to JMSBindingContext which allow extensions to set/get java.lang.Object based upon a string key. 2) Update JMSBindingProcessor.read() to allow for the extension processor to resolve models for wireformats and operation selectors. -- 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-3992) AccessControlException occurs when calling SCAClientFactory.getService
[ https://issues.apache.org/jira/browse/TUSCANY-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-3992. -- Resolution: Fixed Patch applied, thanks for the fix Greg. AccessControlException occurs when calling SCAClientFactory.getService -- Key: TUSCANY-3992 URL: https://issues.apache.org/jira/browse/TUSCANY-3992 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Priority: Minor Attachments: TUSCANY-3992.patch If a Java2 security manager is active, an application's call to SCAClientFactory.getService() may fail with an AccessControlException. java.security.AccessControlException: Access denied (java.lang.RuntimePermission accessDeclaredMembers) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1689) at java.lang.Class.checkMemberAccess(Class.java:107) at java.lang.Class.getDeclaredMethods(Class.java:675) at org.apache.tuscany.sca.interfacedef.java.impl.JavaIntrospectionHelper.getMethods(JavaIntrospectionHelper.java:621) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:150) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:80) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:56) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.getInterfaceContract(ComponentContextImpl.java:472) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createEndpointReference(ComponentContextImpl.java:423) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createEndpointReference(ComponentContextImpl.java:399) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createSelfReference(ComponentContextImpl.java:300) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createSelfReference(ComponentContextImpl.java:254) at org.apache.tuscany.sca.core.assembly.impl.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:134) at org.apache.tuscany.sca.client.impl.SCAClientFactoryImpl.getService(SCAClientFactoryImpl.java:98) I have attached a patch that resolves the problem. -- 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-3998) Provide a way to override Tuscany system definition.xml documents
[ https://issues.apache.org/jira/browse/TUSCANY-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-3998. -- Resolution: Fixed Patches applied, thanks for the fix Greg. Provide a way to override Tuscany system definition.xml documents --- Key: TUSCANY-3998 URL: https://issues.apache.org/jira/browse/TUSCANY-3998 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: ant elder Priority: Minor Attachments: TUSCANY-3998-revised.patch A Tuscany embedder may need to change certain system definitions, e.g. a bindingType or an implementationType. System definitions are found using the ServiceDiscovery mechanism. DefaultDefinitionsExtensionPoint looks for jars/bundles that have a META-INF/services/org.apache.tuscany.sca.definitions.xml.Definitions file. definitionsDeclarations = registry.getServiceDiscovery().getServiceDeclarations(DEFINITIONS_FILE); This collects all definitions documents in the runtime. There is no way to override one definitions document with another. I am attaching a patch to address this. It changes the getServiceDeclarations() call to get declarations in ranked order. When processing the returned declarations, it now processes only the first resource with a given path. The embedder's service declaration must use the same resource name as the Tuscany definition it replaces and it must have a higher ranking attribute. -- 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] [Assigned] (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 reassigned TUSCANY-4001: -- Assignee: ant elder 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: Happy new year to one an all!
Yes happy new year everyone. ...ant 2012/1/3 Giorgio Zoppi giorgio.zo...@gmail.com: +1 happy new year! -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. Favola -Moda.
Re: Fwd: Dynamic service references (summary)
On Tue, Dec 13, 2011 at 9:31 AM, ant elder antel...@apache.org wrote: I've committed some changes so that you can use some Tuscany versions of the OASIS ComponentContext and ServiceReference interfaces. There's an example of them being used to dynamically alter a Web service reference URL at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/testing/itest/dynamicRefURI/src/main/java/org/apache/tuscany/sca/itest/HelloworldClient.java I've not yet added this to all the OASIS ComponentContext methods (eg getServiceReferences) and there is now some rationalization of the Tuscany interfaces and classes I think we should do (eg ServiceReferenceExt among others), but this gives an idea of what we could do. I've not done anything with wiredByImpl either as i'm still not sure its terribly useful. I did have a look at changing ComponentContext.getServiceReferences method to support this but it doesn't seem so easy so it continues to return ServiceReference objects and they'd need to be cast to TuscanyServiceReference to get the Tuscany specific function. ...ant
[jira] [Assigned] (TUSCANY-3998) Provide a way to override Tuscany system definition.xml documents
[ https://issues.apache.org/jira/browse/TUSCANY-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-3998: -- Assignee: ant elder Provide a way to override Tuscany system definition.xml documents --- Key: TUSCANY-3998 URL: https://issues.apache.org/jira/browse/TUSCANY-3998 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: ant elder Priority: Minor Attachments: TUSCANY-3998.patch A Tuscany embedder may need to change certain system definitions, e.g. a bindingType or an implementationType. System definitions are found using the ServiceDiscovery mechanism. DefaultDefinitionsExtensionPoint looks for jars/bundles that have a META-INF/services/org.apache.tuscany.sca.definitions.xml.Definitions file. definitionsDeclarations = registry.getServiceDiscovery().getServiceDeclarations(DEFINITIONS_FILE); This collects all definitions documents in the runtime. There is no way to override one definitions document with another. I am attaching a patch to address this. It changes the getServiceDeclarations() call to get declarations in ranked order. When processing the returned declarations, it now processes only the first resource with a given path. The embedder's service declaration must use the same resource name as the Tuscany definition it replaces and it must have a higher ranking attribute. -- 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-3998) Provide a way to override Tuscany system definition.xml documents
[ https://issues.apache.org/jira/browse/TUSCANY-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-3998. -- Resolution: Fixed Patch applied, thanks for the code Greg. Provide a way to override Tuscany system definition.xml documents --- Key: TUSCANY-3998 URL: https://issues.apache.org/jira/browse/TUSCANY-3998 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: ant elder Priority: Minor Attachments: TUSCANY-3998.patch A Tuscany embedder may need to change certain system definitions, e.g. a bindingType or an implementationType. System definitions are found using the ServiceDiscovery mechanism. DefaultDefinitionsExtensionPoint looks for jars/bundles that have a META-INF/services/org.apache.tuscany.sca.definitions.xml.Definitions file. definitionsDeclarations = registry.getServiceDiscovery().getServiceDeclarations(DEFINITIONS_FILE); This collects all definitions documents in the runtime. There is no way to override one definitions document with another. I am attaching a patch to address this. It changes the getServiceDeclarations() call to get declarations in ranked order. When processing the returned declarations, it now processes only the first resource with a given path. The embedder's service declaration must use the same resource name as the Tuscany definition it replaces and it must have a higher ranking attribute. -- 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: [jira] [Commented] (TUSCANY-3850) Tuscany 1.6 RMI bug: ConnectException after component restart
Sorry, i'll go apply that now. ...ant On Wed, Dec 14, 2011 at 9:52 AM, Millies, Sebastian sebastian.mill...@softwareag.com wrote: Hello there, when looking at the 1.x trunk recently for another reason, I noticed that my patch for TUSCANY-3850 has never been applied. If there is a problem with that patch, is there a way I could improve it? -- Sebastian -Original Message- From: ant elder (JIRA) [mailto:dev@tuscany.apache.org] Sent: Wednesday, March 23, 2011 9:22 AM To: Millies, Sebastian Subject: [jira] [Commented] (TUSCANY-3850) Tuscany 1.6 RMI bug: ConnectException after component restart [ https://issues.apache.org/jira/browse/TUSCANY-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010025#comment-13010025 ] ant elder commented on TUSCANY-3850: Thanks for the patch Sebastian, i'll go look at getting it applied. Tuscany 1.6 RMI bug: ConnectException after component restart - Key: TUSCANY-3850 URL: https://issues.apache.org/jira/browse/TUSCANY-3850 Project: Tuscany Issue Type: Bug Components: Java SCA Misc Binding Extensions Affects Versions: Java-SCA-1.6.1 Environment: Java 1.6.0_24, Eclipse Helios, Win XP SP3 Reporter: Sebastian Millies Attachments: RMIReferenceInvoker.zip, TuscanyRMI.zip When I have a network of components connected by RMI references, then restarting a component will cause a java.net.ConnectException in all dependent components on the next remote method call. I suspect some kind of connection factory caches out-of-date information. Example: ServerComponent exposes service Server with an RMI binding on port 8777. ClientComponent exposes service Client with an RMI binding on port 8666 and has a reference to the service Server. ClientTest is a non-SCA Java class that exercises the Client service over RMI. Everything works fine until the ServerComponent Java process is stopped and re-started. The tester will then fail, because the client cannot re-establish the connection to the server. I attach a zip-file with the example. Steps to reproduce the problem: Run ServerLauncher Run ClientLauncher Run ClientTest Stop process in which server is running Re-Run ServerLauncher Re-Run ClientTest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira IDS Scheer Consulting GmbH Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 http://www.softwareag.com
[jira] [Closed] (TUSCANY-3850) Tuscany 1.6 RMI bug: ConnectException after component restart
[ https://issues.apache.org/jira/browse/TUSCANY-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-3850. -- Resolution: Fixed Patch applied to 1.x and 2.x streams, thanks for the fix Sebastian. Tuscany 1.6 RMI bug: ConnectException after component restart - Key: TUSCANY-3850 URL: https://issues.apache.org/jira/browse/TUSCANY-3850 Project: Tuscany Issue Type: Bug Components: Java SCA Misc Binding Extensions Affects Versions: Java-SCA-1.6.1 Environment: Java 1.6.0_24, Eclipse Helios, Win XP SP3 Reporter: Sebastian Millies Fix For: Java-SCA-1.x Attachments: RMIReferenceInvoker.zip, TuscanyRMI.zip When I have a network of components connected by RMI references, then restarting a component will cause a java.net.ConnectException in all dependent components on the next remote method call. I suspect some kind of connection factory caches out-of-date information. Example: ServerComponent exposes service Server with an RMI binding on port 8777. ClientComponent exposes service Client with an RMI binding on port 8666 and has a reference to the service Server. ClientTest is a non-SCA Java class that exercises the Client service over RMI. Everything works fine until the ServerComponent Java process is stopped and re-started. The tester will then fail, because the client cannot re-establish the connection to the server. I attach a zip-file with the example. Steps to reproduce the problem: Run ServerLauncher Run ClientLauncher Run ClientTest Stop process in which server is running Re-Run ServerLauncher Re-Run ClientTest -- 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: [jira] [Commented] (TUSCANY-3850) Tuscany 1.6 RMI bug: ConnectException after component restart
I've applied this fix to the 1.x and 2.x trunks now. ...ant On Wed, Dec 14, 2011 at 10:49 AM, ant elder ant.el...@gmail.com wrote: Sorry, i'll go apply that now. ...ant On Wed, Dec 14, 2011 at 9:52 AM, Millies, Sebastian sebastian.mill...@softwareag.com wrote: Hello there, when looking at the 1.x trunk recently for another reason, I noticed that my patch for TUSCANY-3850 has never been applied. If there is a problem with that patch, is there a way I could improve it? -- Sebastian -Original Message- From: ant elder (JIRA) [mailto:dev@tuscany.apache.org] Sent: Wednesday, March 23, 2011 9:22 AM To: Millies, Sebastian Subject: [jira] [Commented] (TUSCANY-3850) Tuscany 1.6 RMI bug: ConnectException after component restart [ https://issues.apache.org/jira/browse/TUSCANY-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010025#comment-13010025 ] ant elder commented on TUSCANY-3850: Thanks for the patch Sebastian, i'll go look at getting it applied. Tuscany 1.6 RMI bug: ConnectException after component restart - Key: TUSCANY-3850 URL: https://issues.apache.org/jira/browse/TUSCANY-3850 Project: Tuscany Issue Type: Bug Components: Java SCA Misc Binding Extensions Affects Versions: Java-SCA-1.6.1 Environment: Java 1.6.0_24, Eclipse Helios, Win XP SP3 Reporter: Sebastian Millies Attachments: RMIReferenceInvoker.zip, TuscanyRMI.zip When I have a network of components connected by RMI references, then restarting a component will cause a java.net.ConnectException in all dependent components on the next remote method call. I suspect some kind of connection factory caches out-of-date information. Example: ServerComponent exposes service Server with an RMI binding on port 8777. ClientComponent exposes service Client with an RMI binding on port 8666 and has a reference to the service Server. ClientTest is a non-SCA Java class that exercises the Client service over RMI. Everything works fine until the ServerComponent Java process is stopped and re-started. The tester will then fail, because the client cannot re-establish the connection to the server. I attach a zip-file with the example. Steps to reproduce the problem: Run ServerLauncher Run ClientLauncher Run ClientTest Stop process in which server is running Re-Run ServerLauncher Re-Run ClientTest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira IDS Scheer Consulting GmbH Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 http://www.softwareag.com
Re: Fwd: Dynamic service references (summary)
On Fri, Dec 9, 2011 at 2:24 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 2:16 PM, ant elder antel...@apache.org wrote: On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote: On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant IIRC the OASIS annotation code is smart enough (or can be made that way) to inject the right thing based on the Type of the field to be injected. We could gate this algorithm based on whether the reference is marked as wire by impl. I.e. are you allowed to affect the wiring from within the implementation. The assembly spec says this about wiredByImpl If set to true it indicates that the target of the 353 reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint 354 reference by some means and setting this as the target of the reference through the use of 355 programming interfaces defined by the relevant Client and Implementation specification).If 356 @wiredByImpl is set to true, then any reference targets configured for this reference MUST be 357 ignored by the runtime. [ASM40006] I've never been sure whether implementation here refers to the component implementation or the component implementation type (the infrastructure code) or either. I supposed there's nothing stopping us from making the feature available regardless of whether wiredByImpl is set but. if nothing else, we could use it to explain what wiredByImpl is for. The issues I have with having wiredByImpl control whether or not this is possible are that it defaults to false and if its true then you can't have a default for the reference defined in the SCDL (asm40006). Perhaps I don't understand the reasoning behind those but it seems more useable the other way around to me. ...ant That's what I was saying at the end (I think) that we make the facility available regardless but turning wiredByImpl on means that you have to use it. It you don't turn wiredByImpl on you can either set the reference through the new API or rely on the target in the SCDL. I've committed some changes so that you can use some Tuscany versions of the OASIS ComponentContext and ServiceReference interfaces. There's an example of them being used to dynamically alter a Web service reference URL at: https://svn.apache.org/repos
Re: Fwd: Dynamic service references (summary)
On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant
Re: Fwd: Dynamic service references (summary)
On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote: On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant IIRC the OASIS annotation code is smart enough (or can be made that way) to inject the right thing based on the Type of the field to be injected. We could gate this algorithm based on whether the reference is marked as wire by impl. I.e. are you allowed to affect the wiring from within the implementation. The assembly spec says this about wiredByImpl If set to true it indicates that the target of the 353 reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint 354 reference by some means and setting this as the target of the reference through the use of 355 programming interfaces defined by the relevant Client and Implementation specification).If 356 @wiredByImpl is set to true, then any reference targets configured for this reference MUST be 357 ignored by the runtime. [ASM40006] I've never been sure whether implementation here refers to the component implementation or the component implementation type (the infrastructure code) or either. I supposed there's nothing stopping us from making the feature available regardless of whether wiredByImpl is set but. if nothing else, we could use it to explain what wiredByImpl is for. The issues I have with having wiredByImpl control whether or not this is possible are that it defaults to false and if its true then you can't have a default for the reference defined in the SCDL (asm40006). Perhaps I don't understand the reasoning behind those but it seems more useable the other way around to me. ...ant
Re: Runtime properties reference?
On Thu, Dec 8, 2011 at 2:22 PM, Simon Laws simonsl...@googlemail.com wrote: I note that the TuscanyRuntime class allows properties to be passed in to the constructor. Is there a reference/help somewhere that lists what properties are supported? The interface org.apache.tuscany.sca.runtime.RuntimeProperties has constants for some of the ones that are supported. ...ant
Re: Fwd: Dynamic service references (summary)
On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant
Happy Birthday Tuscany
Its six years today since Tuscany started as an incubator project at the ASF [1]. ...ant [1] http://apache.markmail.org/message/sc4h3eyfo46tlbfp
Fwd: Dynamic service references (summary)
This is good and i will have a go in 2.x to see if a similar approach
works there. But i can't help thinking its a slightly convoluted
approach and as we have more flexibility in 2.x to add more APIs I
wonder if we should just add a more direct API method to set the URIs
with extra methods on Node, or also perhaps something like being able
to do: ((TuscanyServiceReference)serviceReference).setURI(uri)?
...ant
-- Forwarded message --
From: Simon Nash n...@apache.org
Date: Wed, Dec 7, 2011 at 1:04 PM
Subject: Re: Dynamic service references (summary)
To: u...@tuscany.apache.org
Millies, Sebastian wrote:
Thank you very much for all your help, Simon.
You're very welcome. I'm glad this is working for you now.
I summarize here the result of this discussion for everyone's benefit:
For dynamic web service endpoints, get a wsdl for the web service and define
a service reference with interface.wsdl using wsdl.binding and a dummy
URI in the binding.ws element.
One small point--it doesn't need to be interface.wsdl. It should also work
if you use interface.java.
Simon
sca:reference name=bapiCostcenterGetList requires=sca:authentication
sca:interface.wsdl
interface=urn:functions#wsdl.interface(ZWS_BAPI_COSTCENTER_GETLIST) /
sca:binding.ws
wsdlElement=urn:functions#wsdl.binding(ZWS_BAPI_COSTCENTER_GETLISTBinding)
uri=dynamicURI /
/sca:reference
At run time get the service reference, serialize it to XML, replace the
dummy URI with the real endpoint URI, deserialize the reference and call the
service method. The serialization coding goes like this:
public String serializeServiceReferenceXML( ServiceReferenceT sr )
throws IOException
{
ServiceReferenceImplT sri = (ServiceReferenceImplT) sr;
return sri.toXMLString();
}
public ServiceReferenceT deserializeServiceReferenceXML( String
serializedSR )
throws Exception
{
StringReader reader = new StringReader( serializedSR );
XMLStreamReader xmlReader =
XMLInputFactory.newInstance().createXMLStreamReader( reader );
ServiceReferenceImplT sri = new ServiceReferenceImplT( xmlReader );
return sri;
}
The deserialized reference will work also when using policy sets (I have
tested
that with basic authentication).
For background on the changes that have been made to the 1.x trunk to make
this possible, refer to TUSCANY-3984.
-- Sebastian
IDS Scheer Consulting GmbH
Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev
Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany -
Registergericht/Commercial register: Saarbrücken HRB 19681
http://www.softwareag.com
[jira] [Closed] (TUSCANY-3965) In a Service Implementation annotated with @Service, it's unannonated properties should not be introspected
[
https://issues.apache.org/jira/browse/TUSCANY-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder closed TUSCANY-3965.
--
Resolution: Fixed
This was caused by a bug in HeuristicPojoProcessor which i've fixed in r1210426
In a Service Implementation annotated with @Service, it's unannonated
properties should not be introspected
---
Key: TUSCANY-3965
URL: https://issues.apache.org/jira/browse/TUSCANY-3965
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0-Beta1
Environment: All
Reporter: Hasan Muhammad
Assignee: Simon Laws
Priority: Critical
Fix For: Java-SCA-2.x
I was trying to deploy a composite which has component implementing a java
implementation annotated with @Service which has the following field
@Service(TestOasis.class)
public class TestOasisImpl implements TestOasis {
@DefaultHelperContext
protected HelperContext helperContext;
This is not a property as it clearly does not have a @Property annotation and
hence the composite definition does not define this property. However, the
validation is logging this as an error as follows
[Composite: {http://docs.oasis-open.org/ns/opencsa/sca/200912}, Component:
SDOSimpleServiceJavaSerOasis] - No type specified on component property:
Component = SDOSimpleServiceJavaSerOasis Property = helperContext
This is coming from org.apache.tuscany.sca.builder.impl.ComponentBuilderImpl
and the message ID is NoTypeForComponentProperty
This validation is too strict and we should ignore properties defined in
Service class which are not annotated with @Property. The CI spec section 8.1
appears to confirm to this deduction.
--
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] [Reopened] (TUSCANY-3965) In a Service Implementation annotated with @Service, it's unannonated properties should not be introspected
[
https://issues.apache.org/jira/browse/TUSCANY-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder reopened TUSCANY-3965:
Assignee: (was: Simon Laws)
There is a still an issue with introspection of properties for @Service
annotated classes. The previous fix just fixes fields annotated with non-sca
annotations getting used as properties. So reopening.
In a Service Implementation annotated with @Service, it's unannonated
properties should not be introspected
---
Key: TUSCANY-3965
URL: https://issues.apache.org/jira/browse/TUSCANY-3965
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0-Beta1
Environment: All
Reporter: Hasan Muhammad
Priority: Critical
Fix For: Java-SCA-2.x
I was trying to deploy a composite which has component implementing a java
implementation annotated with @Service which has the following field
@Service(TestOasis.class)
public class TestOasisImpl implements TestOasis {
@DefaultHelperContext
protected HelperContext helperContext;
This is not a property as it clearly does not have a @Property annotation and
hence the composite definition does not define this property. However, the
validation is logging this as an error as follows
[Composite: {http://docs.oasis-open.org/ns/opencsa/sca/200912}, Component:
SDOSimpleServiceJavaSerOasis] - No type specified on component property:
Component = SDOSimpleServiceJavaSerOasis Property = helperContext
This is coming from org.apache.tuscany.sca.builder.impl.ComponentBuilderImpl
and the message ID is NoTypeForComponentProperty
This validation is too strict and we should ignore properties defined in
Service class which are not annotated with @Property. The CI spec section 8.1
appears to confirm to this deduction.
--
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-3975) Missing Extension processing in WebServiceBindingProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162074#comment-13162074 ] ant elder commented on TUSCANY-3975: The WSDLI check was added in r1200809 to fix the compliance fail. Missing Extension processing in WebServiceBindingProcessor class Key: TUSCANY-3975 URL: https://issues.apache.org/jira/browse/TUSCANY-3975 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Rashmi Hunt Assignee: ant elder Fix For: Java-SCA-2.x Attachments: TUSCANY-3975.patch I have attached a patch which adds extension processing in WebServiceBindingProcessor -- 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] [Resolved] (TUSCANY-3975) Missing Extension processing in WebServiceBindingProcessor class
[ https://issues.apache.org/jira/browse/TUSCANY-3975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder resolved TUSCANY-3975. Resolution: Fixed Patch applied, thanks for the fix Rashmi Missing Extension processing in WebServiceBindingProcessor class Key: TUSCANY-3975 URL: https://issues.apache.org/jira/browse/TUSCANY-3975 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Rashmi Hunt Assignee: ant elder Fix For: Java-SCA-2.x Attachments: TUSCANY-3975.patch I have attached a patch which adds extension processing in WebServiceBindingProcessor -- 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] [Resolved] (TUSCANY-3974) IntentNotSatisfiedAtBuild error occurs when using an intent provided by implementation
[ https://issues.apache.org/jira/browse/TUSCANY-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder resolved TUSCANY-3974. Resolution: Fixed Patch applied, thanks for the fix Greg. IntentNotSatisfiedAtBuild error occurs when using an intent provided by implementation -- Key: TUSCANY-3974 URL: https://issues.apache.org/jira/browse/TUSCANY-3974 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: ant elder Priority: Minor Attachments: TUSCANY-3974.patch ComponentPolicyBuilderImpl.checkIntentsResolved() isn't finding the mayProvides/alwaysProvides intent list for an implementation type. I've attached a fix. -- 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-3979) Several of the binding-ws-runtime modules unit tests fail when building with JDK7
Several of the binding-ws-runtime modules unit tests fail when building with JDK7 - Key: TUSCANY-3979 URL: https://issues.apache.org/jira/browse/TUSCANY-3979 Project: Tuscany Issue Type: Bug Reporter: ant elder Fix For: Java-SCA-2.0 Several of the binding-ws-runtime modules unit tests fail when building with JDK7 -- 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-3978) The common-xml module DOMHelperTestCase testPool tests fail when running with JDK7
The common-xml module DOMHelperTestCase testPool tests fail when running with JDK7 -- Key: TUSCANY-3978 URL: https://issues.apache.org/jira/browse/TUSCANY-3978 Project: Tuscany Issue Type: Bug Reporter: ant elder Fix For: Java-SCA-2.0 The common-xml module DOMHelperTestCase testPool tests fail when running with JDK7 -- 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-3981) Assembly compliance test failures when running with JDK7
Assembly compliance test failures when running with JDK7 Key: TUSCANY-3981 URL: https://issues.apache.org/jira/browse/TUSCANY-3981 Project: Tuscany Issue Type: Bug Reporter: ant elder Fix For: Java-SCA-2.0 There are some Assembly compliance test failures when running with JDK7 -- 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
