[jira] Created: (TUSCANY-2389) null elements in Object array not getting passed over binding.ws
null elements in Object array not getting passed over binding.ws Key: TUSCANY-2389 URL: https://issues.apache.org/jira/browse/TUSCANY-2389 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am noticing that if there are null values in an Object array that is used as a parameter to a service method invoked over binding.ws, the null values have been eliminated and the array seen in the implementation is actually shorter than the original array. See StandardTypesDatabindingTestCase.testWSNewObjectArray(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2385) Problem with Databinding for URI and UUID objects when using binding.ws
[ https://issues.apache.org/jira/browse/TUSCANY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2385. Problem with Databinding for URI and UUID objects when using binding.ws --- Key: TUSCANY-2385 URL: https://issues.apache.org/jira/browse/TUSCANY-2385 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next I am noticing that when I am invoking a service method that takes an object as parameter over binding.ws,, the URI and UUID standard types that map to xs:string XML data type are being presented to the service method as String rather than their respective types. See StandardTypesDatabindingTestCase.testWSNewObject() under sca\itest\databindings\jaxb-bottom-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
binding.ws in combination with doc/lit/unwrapped wsdl
My java interface: org.apache.tuscany.sca.vtest.wsbinding.AService.
@Remotable
public interface AService {
public String getGreetings(String name);
}
I have the following wsdl, which I assume is doc/lit/unwrapped or bare.
wsdl:definitions targetNamespace=
http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/;
xmlns:ns0=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/;
xmlns:http=http://schemas.xmlsoap.org/wsdl/http/;
xmlns:ns1=http://org.apache.axis2/xsd;
xmlns:wsaw=http://www.w3.org/2006/05/addressing/wsdl;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
xs:schema attributeFormDefault=qualified
elementFormDefault=qualified targetNamespace=
http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:ns=
http://wsbinding.vtest.sca.tuscany.apache.org;
xs:element minOccurs=0 name=getGreetings nillable=true
type=xs:string/
xs:element minOccurs=0 name=getGreetingsResponse
nillable=true type=xs:string/
/xs:schema
/wsdl:types
wsdl:message name=getGreetingsRequest
wsdl:part name=parameters element=ns0:getGreetings/
/wsdl:message
wsdl:message name=getGreetingsResponse
wsdl:part name=parameters element=ns0:getGreetingsResponse/
/wsdl:message
wsdl:portType name=AServicePortType
wsdl:operation name=getGreetings
wsdl:input message=ns0:getGreetingsRequest
wsaw:Action=urn:getGreetings/
wsdl:output message=ns0:getGreetingsResponse
wsaw:Action=urn:getGreetingsResponse/
/wsdl:operation
/wsdl:portType
wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType
soap12:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap12:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap12:body use=literal/
/wsdl:input
wsdl:output
soap12:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType
soap:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType
http:binding verb=POST/
wsdl:operation name=getGreetings
http:operation location=AService/getGreetings/
wsdl:input
mime:content part=getGreetings type=text/xml/
/wsdl:input
wsdl:output
mime:content part=getGreetings type=text/xml/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType
soap:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=AServicePortTypeService
wsdl:port name=AServicePortTypePort
binding=ns0:AServicePortTypeBinding
soap:address location=http://localhost:8080/AService/
/wsdl:port
/wsdl:service
wsdl:service name=AService
wsdl:port name=AServiceHttpport binding=ns0:AServiceHttpBinding
http:address location=http://localhost:8080/AService/httpport/
/wsdl:port
wsdl:port name=AServiceSOAP12port_http
binding=ns0:AServiceSOAP12Binding
soap12:address location=http://localhost:8080/AService/soap12port/
/wsdl:port
wsdl:port name=AServiceSOAP11port_http
binding=ns0:AServiceSOAP11Binding
soap:address location=http://localhost:8080/AService/soap11port/
/wsdl:port
wsdl:port name=AServiceSOAP12port_http_null
binding=ns0:AServiceSOAP12Binding
soap12:address location=/
/wsdl:port
wsdl:port name=AServiceSOAP12port_http_wsdl
binding=ns0:AServiceSOAP12Binding
soap12:address location=inWsdl/
/wsdl:port
/wsdl:service
/wsdl:definitions
The following diff should tell how I got this wsdl:
Index:
D:/T/java/sca/vtest/wsbinding/service/src/main/resources/aservice.wsdl
===
--- D:/T/java/sca/vtest/wsbinding/service/src/main/resources/aservice.wsdl
(revision 667316)
+++ D:/T/java/sca/vtest/wsbinding/service/src/main/resources/aservice.wsdl
(working copy)
@@ -29,20 +29,8 @@
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
Re: binding.ws in combination with doc/lit/unwrapped wsdl
Scott,
You are right. Adding @SOAPBinding annotation lead to further problems with
wsdl generation.
++Vamsi
On Fri, Jun 13, 2008 at 7:51 PM, Scott Kurz [EMAIL PROTECTED] wrote:
Vamsi,
It looks like all your failure cases require runtime Java2WSDL. In order
to generate a doc-lit-unwrapped WSDL from Java,
the Java should contain annotation:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
I believe this the new rewrite of the Java2WSDL code that Simon Nash did
doesn't handle this yet. But it seems like these
tests you did will be good ones to start with when someone does get the
time
to work on this.
Scott
On Fri, Jun 13, 2008 at 9:57 AM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
My java interface: org.apache.tuscany.sca.vtest.wsbinding.AService.
@Remotable
public interface AService {
public String getGreetings(String name);
}
I have the following wsdl, which I assume is doc/lit/unwrapped or bare.
wsdl:definitions targetNamespace=
http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/;
xmlns:ns0=
http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/;
xmlns:http=http://schemas.xmlsoap.org/wsdl/http/;
xmlns:ns1=http://org.apache.axis2/xsd;
xmlns:wsaw=http://www.w3.org/2006/05/addressing/wsdl;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
xs:schema attributeFormDefault=qualified
elementFormDefault=qualified targetNamespace=
http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:ns=
http://wsbinding.vtest.sca.tuscany.apache.org;
xs:element minOccurs=0 name=getGreetings nillable=true
type=xs:string/
xs:element minOccurs=0 name=getGreetingsResponse
nillable=true type=xs:string/
/xs:schema
/wsdl:types
wsdl:message name=getGreetingsRequest
wsdl:part name=parameters element=ns0:getGreetings/
/wsdl:message
wsdl:message name=getGreetingsResponse
wsdl:part name=parameters element=ns0:getGreetingsResponse/
/wsdl:message
wsdl:portType name=AServicePortType
wsdl:operation name=getGreetings
wsdl:input message=ns0:getGreetingsRequest
wsaw:Action=urn:getGreetings/
wsdl:output message=ns0:getGreetingsResponse
wsaw:Action=urn:getGreetingsResponse/
/wsdl:operation
/wsdl:portType
wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType
soap12:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap12:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap12:body use=literal/
/wsdl:input
wsdl:output
soap12:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServicePortTypeBinding
type=ns0:AServicePortType
soap:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType
http:binding verb=POST/
wsdl:operation name=getGreetings
http:operation location=AService/getGreetings/
wsdl:input
mime:content part=getGreetings type=text/xml/
/wsdl:input
wsdl:output
mime:content part=getGreetings type=text/xml/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType
soap:binding style=document transport=
http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=AServicePortTypeService
wsdl:port name=AServicePortTypePort
binding=ns0:AServicePortTypeBinding
soap:address location=http://localhost:8080/AService/
/wsdl:port
/wsdl:service
wsdl:service name=AService
wsdl:port name=AServiceHttpport binding=ns0:AServiceHttpBinding
http:address location=http://localhost:8080/AService/httpport/
/wsdl:port
wsdl:port name=AServiceSOAP12port_http
binding=ns0:AServiceSOAP12Binding
soap12:address location=http://localhost:8080/AService/soap12port
/
/wsdl:port
wsdl:port name=AServiceSOAP11port_http
binding=ns0
Re: Good practice for disabling/ignoring failing test cases
Shouldn't be a big problem. We can get rid of those commented ones from
code as soon as we find them.
++Vamsi
On Thu, Jun 12, 2008 at 11:35 AM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
It seems that you need to improve the script to filter out the @Ignore
annotations in the java comments :-).
For example,
// @Ignore
// @Ignore(TUSCANY-2349)
Thanks,
Raymond
--
From: Kevin Williams [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 10:26 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Good practice for disabling/ignoring failing test cases
Since the vtest script assumes a test comment structure around
specification line numbers, I created a new script specific to this
purpose and added it to /java/etc. It scans for files named
*testCase.java and collects methods annotated with @Ignore.
I could use some help getting this automated but, in the meantime,
I'll run this scan weekly and post results to the dev-list
Here is output from tonight's scan:
-
Content generated by from C:/tuscanysvn/java/sca
Test case files scanned 2008-06-11 (svn:Revision: 663374)
* Total files processed = 591
* Total ingnored test cases = 26
The following test cases have ignored test methods ...
org.apache.tuscany.sca.itest.databindings.jaxb.DatabindingTestCase
testWSMap() , no associated jira
testWSHashMap() , no associated jira
org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase
testSCANegateByteArray() , T-2351
testWSNegateByteArray() , T-2349
org.apache.tuscany.sca.itest.references.ManualWiredReferenceTestCase
testD2Reference() , no associated jira
client.CatalogEJBClientTestCase
testCatalogEJB() , no associated jira
org.apache.tuscany.sca.vtest.assembly.ctypefile.CompomnentTypeFileTestCase
typeFile3() , T-2383
org.apache.tuscany.sca.vtest.javaapi.annotations.conversationattributes.ConversationAttributesAnnotationTestCase
singlePrincipal() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.annotations.property.PropertyAnnotationTestCase
atProperty7() , T-2289
org.apache.tuscany.sca.vtest.javaapi.annotations.reference.ReferenceAnnotationTestCase
bogusComponentName() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase
atScope1() , T-2274
atScope7() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.ComponentContextTestCase
testGetRequestContext() , no associated jira
testServiceLookup() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.apis.exception.ExceptionTestCase
testServiceUnavailableException() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.apis.requestcontext.RequestContextTestCase
testGetSecuritySubject() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase
statefulMixedCallback() , T-2291
statelessCallback3() , T-2306
customCallback() , T-2312
org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.LifetimeTestCase
lifetime2() , T-2243
lifetime11() , T-2283
org.apache.tuscany.sca.vtest.wsbinding.nowsdl.multisoapbindings.GeneratedWSDLTestCase
testMultiSoapBindings4() , no associated jira
org.apache.tuscany.sca.vtest.wsbinding.nowsdl.soapversion.GeneratedWSDLTestCase
testSoapVersion4() , no associated jira
testSoapVersion5() , no associated jira
org.apache.tuscany.sca.vtest.wsbinding.WsdlEndpointTestCase
testWsdlEndpoint() , no associated jira
org.apache.tuscany.sca.vtest.wsbinding.WsdlServiceTestCase
testWsdlService() , T-2298
On Wed, Jun 11, 2008 at 6:42 PM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Simon Laws wrote:
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy
[EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in
Tuscany
source code and have been following it consistently from then on.
Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA
TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
+1
--
Jean-Sebastien
[jira] Commented: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604180#action_12604180 ] Vamsavardhana Reddy commented on TUSCANY-2371: -- Completed: At revision: 18 o Fix javax.xml.transform.Source related tests. The Source returned may use a different type of Source. Compare the content instead of using equals(). Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2371.patch Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2371. Resolution: Fixed Assignee: Vamsavardhana Reddy (was: Raymond Feng) Complete. Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2371.patch Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2385) Problem with Databinding for URI and UUID objects when using binding.ws
Problem with Databinding for URI and UUID objects when using binding.ws --- Key: TUSCANY-2385 URL: https://issues.apache.org/jira/browse/TUSCANY-2385 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am noticing that when I am invoking a service method that takes an object as parameter over binding.ws,, the URI and UUID standard types that map to xs:string XML data type are being presented to the service method as String rather than their respective types. See StandardTypesDatabindingTestCase.testWSNewObject() under sca\itest\databindings\jaxb-bottom-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2386) Databinding problem for array of javax.xml.transform.Source with binding.ws
Databinding problem for array of javax.xml.transform.Source with binding.ws --- Key: TUSCANY-2386 URL: https://issues.apache.org/jira/browse/TUSCANY-2386 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am getting a TransformationException with a service method that takes an array of javax.xml.transform.Source objects. See StandardTypesDatabindingTestCase.testWSNewSourceArray() under sca\itest\databindings\jaxb-bottom-up. StackTrace is given below: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:array-org.apache.axiom.om.OMElement at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:165) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:69) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:201) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:45) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:81) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy21.getNewSourceArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.StandardTypesLocalServiceClientImpl.getNewSourceArrayForward(StandardTypesLocalServiceClientImpl.java:147) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:111) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy20.getNewSourceArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.performTestNewSourceArray(StandardTypesDatabindingTestCase.java:1300) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.testWSNewSourceArray(StandardTypesDatabindingTestCase.java:649) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460
[jira] Created: (TUSCANY-2387) Databinding problem for array of javax.xml.transform.Source with binding.sca and remotable service
Databinding problem for array of javax.xml.transform.Source with binding.sca and remotable service -- Key: TUSCANY-2387 URL: https://issues.apache.org/jira/browse/TUSCANY-2387 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am getting a MarshalException with a remotable service method that takes an array of javax.xml.transform.Source objects invoked over binding.sca. See StandardTypesDatabindingTestCase.testSCANewSourceArray() under sca\itest\databindings\jaxb-bottom-up. StackTrace is given below: java.lang.IllegalArgumentException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: class javax.xml.transform.dom.DOMSource nor any of its super class is known to this context.] at org.apache.tuscany.sca.databinding.jaxb.JAXBDataBinding.copy(JAXBDataBinding.java:117) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.copy(DefaultDataBindingExtensionPoint.java:172) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:241) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:160) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:106) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy21.getNewSourceArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.StandardTypesLocalServiceClientImpl.getNewSourceArrayForward(StandardTypesLocalServiceClientImpl.java:147) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:111) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy20.getNewSourceArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.performTestNewSourceArray(StandardTypesDatabindingTestCase.java:1300) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.testSCANewSourceArray(StandardTypesDatabindingTestCase.java:354) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673
Databinding test for javax.xml.transform.Source problem
I have updated the tests to get the content out of Source objects and compare the contents. I have the following StreamSource as input: new StreamSource(new StringReader(aA/a)). The content I am from this source is as follows: ?xml version=1.0 encoding=UTF-8? aA/a I have a service method that returns a copy of the source that is passed to it. The source that is returned when the service method is invoked over binding.ws is giveing the following content: ?xml version=1.0 encoding=UTF-8? return xmlns=http://jaxb.databindings.itest.sca.tuscany.apache.org/ A/return Notice the namespace and the change in the root tag. Any suggestions on changing the test?
Re: Good practice for disabling/ignoring failing test cases
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
[jira] Closed: (TUSCANY-2378) Databinding tests for generics, parameterized and polymorphic types
[ https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2378. Resolution: Fixed Complete. Databinding tests for generics, parameterized and polymorphic types --- Key: TUSCANY-2378 URL: https://issues.apache.org/jira/browse/TUSCANY-2378 Project: Tuscany Issue Type: Test Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding tests for generics, parameterized and polymorphic types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests
[ https://issues.apache.org/jira/browse/TUSCANY-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2361. Databinding tests for primitives and primitive arrays - local service, pass-by-value tests -- Key: TUSCANY-2361 URL: https://issues.apache.org/jira/browse/TUSCANY-2361 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2361.patch TUSCANY-2350 added databinding tests for primitives and primitive arrays using a remotable service. The same tests need to be done for a local service too (see [1]). Also, the pass-by-value semantics does not seem to be working for byte array. It is a good idea to add tests for pass-by-value for byte array and arrays of other primitive types. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2373) RuntimeException: no data binding for null with binding.ws when the service interface uses generics
[ https://issues.apache.org/jira/browse/TUSCANY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2373. Resolution: Fixed Assignee: Raymond Feng Fixed as part databinding tests cleanup. RuntimeException: no data binding for null with binding.ws when the service interface uses generics - Key: TUSCANY-2373 URL: https://issues.apache.org/jira/browse/TUSCANY-2373 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2373-testcase.patch I have the following method in my service interface that uses binding.ws: T Bean1T getTypeUnbound(T[] anArray); I am getting the following exception in SCADomain.newInstance() org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237) ... 18 more Caused by: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47) at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint
[jira] Closed: (TUSCANY-2356) Databinding itests for Local service
[ https://issues.apache.org/jira/browse/TUSCANY-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2356. Databinding itests for Local service Key: TUSCANY-2356 URL: https://issues.apache.org/jira/browse/TUSCANY-2356 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2356.patch Databinding itests added by TUSCANY-2340 deal with only @Remotable service. This JIRA is for itests for Local service. See [1]. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2340) Databinding integration tests
[ https://issues.apache.org/jira/browse/TUSCANY-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2340. Databinding integration tests - Key: TUSCANY-2340 URL: https://issues.apache.org/jira/browse/TUSCANY-2340 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2340-new.patch, TUSCANY-2340.patch I have been trying out a few tests with databindings and am hitting some TransformationExceptions. I thought it is better I post the tests I am creating to the JIRA so that others can take a look at these tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types
[ https://issues.apache.org/jira/browse/TUSCANY-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2350. Databinding tests for primitive types and array of primitive types -- Key: TUSCANY-2350 URL: https://issues.apache.org/jira/browse/TUSCANY-2350 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2350.patch Databinding tests for primitive types and array of primitive types -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2349) TransformationException when invoking a method with byte array paramter using webservice binding
[ https://issues.apache.org/jira/browse/TUSCANY-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2349. TransformationException when invoking a method with byte array paramter using webservice binding Key: TUSCANY-2349 URL: https://issues.apache.org/jira/browse/TUSCANY-2349 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng I have a service method that takes a byte array as parameter and returns a byte array. When I invoke the method using webservice binding, I am getting a TransformationException: No path found for the transformation: java:simpleType-java:array. The stacktrace is given below: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:simpleType-java:array at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:163) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:67) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:152) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.negateByteArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.PrimitivesServiceClientImpl.negateByteArrayForward(PrimitivesServiceClientImpl.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:110) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.negateByteArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.performTestNegateByteArray(PrimitivesDatabindingTestCase.java:372) at org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.testWSNegateByteArray(PrimitivesDatabindingTestCase.java:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38
[jira] Closed: (TUSCANY-2272) @Init and @Destroy annotations on a non-public method
[ https://issues.apache.org/jira/browse/TUSCANY-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2272. @Init and @Destroy annotations on a non-public method -- Key: TUSCANY-2272 URL: https://issues.apache.org/jira/browse/TUSCANY-2272 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2272.patch Java Common Annotations and APIs Specification v1.00 - Sec 1.2.4 - Lines 265 to 269: 265 An implementation type may allow component implementations to declare lifecycle methods that are 266 called when an implementation is instantiated or the scope is expired. @Init denotes the method to be 267 called upon first use of an instance during the lifetime of the scope (except for composite scoped 268 implementation marked to eagerly initialize, see Section XXX). @Destroy specifies the method to be called 269 when the scope ends. *Note that only public, no argument methods may be annotated as lifecycle methods.* Currently @Init and @Destroy annotations on a protected method do not result in an error or a warning whereas these annotations on a private method result in a warning. Should it result in an error in both cases? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2273) Return value of a method with @Init and @Destroy annotations must be a void
[ https://issues.apache.org/jira/browse/TUSCANY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2273. Return value of a method with @Init and @Destroy annotations must be a void --- Key: TUSCANY-2273 URL: https://issues.apache.org/jira/browse/TUSCANY-2273 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2273.patch Java Common Annotations and APIs v1.00: Sec 1.8.8 @Destroy - Lines 1226 and 1227: 1226 The method must have a void return value and 1227 no arguments. Sec 1.8.11 @Init - Lines 1291 and 1292: 1291 The method must have a void return value and no 1292 arguments. Currently the code checks only for no arguments but not the return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2090) Test for uniqueness of ConversationIds
[ https://issues.apache.org/jira/browse/TUSCANY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2090. Test for uniqueness of ConversationIds -- Key: TUSCANY-2090 URL: https://issues.apache.org/jira/browse/TUSCANY-2090 Project: Tuscany Issue Type: Test Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Nash Fix For: Java-SCA-1.2 Attachments: TUSCANY-2090.patch Add a test for TUSCANY-2077: ConversationIds are not always unique so that there is no regression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field
[ https://issues.apache.org/jira/browse/TUSCANY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2271. Java runtime should not inject property into an unannotated non-public field Key: TUSCANY-2271 URL: https://issues.apache.org/jira/browse/TUSCANY-2271 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime, Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2271-vtest.patch, TUSCANY-2271.patch Java Common Annotations and APIs v1.0 - Sec 1.8.13: 1349 Properties may also be injected via public setter methods even when the @Property annotation is not 1350 present. However, the @Property annotation must be used in order to inject a property onto a non-public 1351 field. In the case where there is no @Property annotation, the name of the property is the same as the 1352 name of the field or setter. Currently the properties are injected into unannotated protected fields too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603856#action_12603856 ] Vamsavardhana Reddy commented on TUSCANY-2371: -- Completed: At revision: 666090 o Fix DataHandler related tests. The DataHandler returned may use a different type of DataSource. Compare the data content instead of using equals(). Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2371.patch Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2378) Databinding tests for generics, parameterized and polymorphic types
[ https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2378: - Description: Databinding tests for generics, parameterized and polymorphic types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope was: Databinding itests for Generics and parameterized types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope Summary: Databinding tests for generics, parameterized and polymorphic types (was: Databinding tests for generics and parameterized types) Databinding tests for generics, parameterized and polymorphic types --- Key: TUSCANY-2378 URL: https://issues.apache.org/jira/browse/TUSCANY-2378 Project: Tuscany Issue Type: Test Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding tests for generics, parameterized and polymorphic types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2378) Databinding tests for generics, parameterized and polymorphic types
[ https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603891#action_12603891 ] Vamsavardhana Reddy commented on TUSCANY-2378: -- Added test for polymorphic type. Revision: 666122 and 666125. Databinding tests for generics, parameterized and polymorphic types --- Key: TUSCANY-2378 URL: https://issues.apache.org/jira/browse/TUSCANY-2378 Project: Tuscany Issue Type: Test Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding tests for generics, parameterized and polymorphic types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Databinding tests for array of java.net.URI
Hi Raymond, Whether or not resolve() works with http://abc, I have a URI created as URI.create(http://abc;).resolve(xyz) and java does not complain about this URI object . The current problem can be restated that this URI object can not be passed in an array of URI objects back and forth between client and service component in case of a remotable service. The URI object can be passed between the client and service components properly when the service method takes an URI as argument. ++Vamsi On Tue, Jun 10, 2008 at 8:33 PM, Raymond Feng [EMAIL PROTECTED] wrote: I think it's a problem in the test case. The resolve() cannot work with http://abc (which abc is treated as a host name). I changed it to http://abc/, then it works well. You can simply create a test case using URIs only without Tuscany in the picture. Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 2:20 AM To: tuscany-dev@ws.apache.org Subject: Databinding tests for array of java.net.URI I am using the following URI's in my test: URI[] uris = new URI[3]; uris[0] = URI.create(a/b/c); uris[1] = URI.create(http://abc;); uris[2] = URI.create(ftp://a/b;); The return value from the service method is inputUri.resolve(uri). One service method takes an uri as input and returns the changed uri as given above. Another method takes an array of uri as input and returns an array of uri where each element in the returned array contains an uri which is changed as given above. The remotable service invoked over binding.sca is able to provide expected return value for uris[1] with the method that takes URI as argument. But, with the method that takes URI array as argument, the return value for uris[1] is not as expected. In the failing case the input uri has (authority = abc, host = abc, path = ) , expected uri has (authority = abc, host = abc, path = uri) and the uri returned from the service method has (authority=abcuri, host = abcuri, path = ). I have verified through the debugger that the array being returned by the service method has the second element as expected. But, once the array is returned to the caller after data transformations, the element is changed. There definitely is a problem with the data transformation.
Re: Databinding tests for array of java.net.URI
Raymond,
The comment junit.framework.AssertionFailedError: expected:http://abcuri
but was:http://abcuri I had in @Ignore in the testcase code may have lead
to some confusion. I agree that uri1.equals(uri2) is not same as
uri1.toString().equals(uri2.toString()). The issue I am trying to bring up,
which I guess I am unsuccessful so far, is that if I have a service method
that takes a URI and returns the same URI back, and if I invoke that
remotable service with uri1 as parameter, the value that is returned (say
uri3) equals uri1 (i.e. uri1.equals(uri3) is true). If I have another
service method that takes a URI[] and returns back the same URI[] and I
invoke this method with an URI array that contains just one element uri1,
then the URI that is returned is not equal to uri1.
uri1 is creating problems when it passed to the service method as an array
element. So, it has to be a data transformation problem.
++Vamsi
On Tue, Jun 10, 2008 at 9:23 PM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Here is a simple test case to prove my point:
public class URITestCase {
@Test
public void testURI() {
URI uri = URI.create(http://abc;);
URI uri1 = uri.resolve(uri);
URI uri2 = URI.create(http://abcxyz;);
Assert.assertEquals(uri1, uri2);
}
}
The Assert will fail, even though the uri1.toString() equals to
uri2.toString().
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 8:26 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Databinding tests for array of java.net.URI
Hi Raymond,
Whether or not resolve() works with http://abc, I have a URI created as
URI.create(http://abc;).resolve(xyz) and java does not complain about
this URI object . The current problem can be restated that this URI
object
can not be passed in an array of URI objects back and forth between client
and service component in case of a remotable service. The URI object can
be
passed between the client and service components properly when the service
method takes an URI as argument.
++Vamsi
On Tue, Jun 10, 2008 at 8:33 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
I think it's a problem in the test case. The resolve() cannot work with
http://abc (which abc is treated as a host name). I changed it to
http://abc/, then it works well.
You can simply create a test case using URIs only without Tuscany in the
picture.
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 2:20 AM
To: tuscany-dev@ws.apache.org
Subject: Databinding tests for array of java.net.URI
I am using the following URI's in my test:
URI[] uris = new URI[3];
uris[0] = URI.create(a/b/c);
uris[1] = URI.create(http://abc;);
uris[2] = URI.create(ftp://a/b;);
The return value from the service method is inputUri.resolve(uri).
One service method takes an uri as input and returns the changed uri as
given above. Another method takes an array of uri as input and returns
an
array of uri where each element in the returned array contains an uri
which
is changed as given above. The remotable service invoked over
binding.sca
is able to provide expected return value for uris[1] with the method
that
takes URI as argument. But, with the method that takes URI array as
argument, the return value for uris[1] is not as expected.
In the failing case the input uri has (authority = abc, host = abc,
path
= ) , expected uri has (authority = abc, host = abc, path = uri)
and
the uri returned from the service method has (authority=abcuri, host =
abcuri, path = ). I have verified through the debugger that the
array
being returned by the service method has the second element as expected.
But, once the array is returned to the caller after data
transformations,
the element is changed. There definitely is a problem with the data
transformation.
Re: Databinding tests for array of java.net.URI
On Wed, Jun 11, 2008 at 12:32 AM, Raymond Feng [EMAIL PROTECTED] wrote:
What I pointed out is the following:
URI.createURI(http//abc).resolve(uri) (toString()==http://abcuri;)
creates a non-equal instance of URI.createURI(http://abcuri;). By the
javadoc of URI, this is violating the rules:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html
Identities
For any URI u, it is always the case that
new URI(u.toString()).equals(u) .
Thanks for the pointer. I think we can now declare
URI.create(http://abc;).resolve(uri)
as a rogue URI (!!?). The javadoc must be wrong because with this rogue
URI, the above identity is not satisfied.
In the test case you have, the expected is
URI.createURI(http//abc).resolve(uri). On the server side, the impl
method produce URI.createURI(http//abc).resolve(uri) and it get
serialized as http://abcuri; (URI.toString()) in the XML doc. On the
client side, the URI is unmarshalled as URI.createURI(http://abcuri;).
That's why two instances are not equal.
I still wonder why it works in the case when an object is passed to the
method and does not work in the case when the same object is passed in an
array!
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 10:47 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Databinding tests for array of java.net.URI
Raymond,
The comment junit.framework.AssertionFailedError: expected:
http://abcuri
but was:http://abcuri I had in @Ignore in the testcase code may have
lead
to some confusion. I agree that uri1.equals(uri2) is not same as
uri1.toString().equals(uri2.toString()). The issue I am trying to bring
up,
which I guess I am unsuccessful so far, is that if I have a service method
that takes a URI and returns the same URI back, and if I invoke that
remotable service with uri1 as parameter, the value that is returned
(say
uri3) equals uri1 (i.e. uri1.equals(uri3) is true). If I have another
service method that takes a URI[] and returns back the same URI[] and I
invoke this method with an URI array that contains just one element uri1,
then the URI that is returned is not equal to uri1.
uri1 is creating problems when it passed to the service method as an array
element. So, it has to be a data transformation problem.
++Vamsi
On Tue, Jun 10, 2008 at 9:23 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
Here is a simple test case to prove my point:
public class URITestCase {
@Test
public void testURI() {
URI uri = URI.create(http://abc;);
URI uri1 = uri.resolve(uri);
URI uri2 = URI.create(http://abcxyz;);
Assert.assertEquals(uri1, uri2);
}
}
The Assert will fail, even though the uri1.toString() equals to
uri2.toString().
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 8:26 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Databinding tests for array of java.net.URI
Hi Raymond,
Whether or not resolve() works with http://abc, I have a URI created as
URI.create(http://abc;).resolve(xyz) and java does not complain
about
this URI object . The current problem can be restated that this URI
object
can not be passed in an array of URI objects back and forth between
client
and service component in case of a remotable service. The URI object
can
be
passed between the client and service components properly when the
service
method takes an URI as argument.
++Vamsi
On Tue, Jun 10, 2008 at 8:33 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
I think it's a problem in the test case. The resolve() cannot work with
http://abc (which abc is treated as a host name). I changed it to
http://abc/, then it works well.
You can simply create a test case using URIs only without Tuscany in
the
picture.
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 2:20 AM
To: tuscany-dev@ws.apache.org
Subject: Databinding tests for array of java.net.URI
I am using the following URI's in my test:
URI[] uris = new URI[3];
uris[0] = URI.create(a/b/c);
uris[1] = URI.create(http://abc;);
uris[2] = URI.create(ftp://a/b;);
The return value from the service method is inputUri.resolve(uri).
One service method takes an uri as input and returns the changed uri
as
given above. Another method takes an array of uri as input and
returns
an
array of uri where each element in the returned array contains an uri
which
is changed as given above. The remotable service invoked over
binding.sca
is able to provide expected return value for uris[1] with the method
that
takes URI as argument. But, with the method that takes URI array as
argument, the return value for uris[1] is not as expected.
In the failing case the input uri has (authority = abc, host =
abc
Re: [NOTICE] Scott Kurz voted as Tuscany committer
Congratulations Scott!! ++Vamsi On Mon, Jun 9, 2008 at 1:18 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PMC has voted for Scott Kurz to become a Tuscany committer. Welcome Scott! ...ant
[jira] Created: (TUSCANY-2378) Databinding tests for generics and parameterized types
Databinding tests for generics and parameterized types -- Key: TUSCANY-2378 URL: https://issues.apache.org/jira/browse/TUSCANY-2378 Project: Tuscany Issue Type: Test Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding itests for Generics and parameterized types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2378) Databinding tests for generics and parameterized types
[ https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603584#action_12603584 ] Vamsavardhana Reddy commented on TUSCANY-2378: -- First set of tests committed. Completed: At revision: 665715 Databinding tests for generics and parameterized types -- Key: TUSCANY-2378 URL: https://issues.apache.org/jira/browse/TUSCANY-2378 Project: Tuscany Issue Type: Test Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding itests for Generics and parameterized types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build error in sca\itest\properties
I am seeing a compilation failure in sca\itest\properties. Is anyone else
hitting this error? Command output given below.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Apache Tuscany SCA Properties Integration Tests
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory D:\T\java\sca\itest\properties\target
[INFO] [tuscany-sdo:generate {execution: generate-customer-sdo}]
[INFO] Generating SDO interfaces from
D:\T\java\sca\itest\properties\src\main\resources\customer.xsd
Generating code
Generating packages
Generating package SdoPackageImpl
Generating Java interface com.example.customer.sdo.SdoFactory
Generating /TargetProject/com/example/customer/sdo/SdoFactory.java
Generating Java class com.example.customer.sdo.impl.SdoFactoryImpl
Generating
/TargetProject/com/example/customer/sdo/impl/SdoFactoryImpl.java
Generating Customer
Generating Java interface com.example.customer.sdo.Customer
Generating /TargetProject/com/example/customer/sdo/Customer.java
Generating Java class com.example.customer.sdo.impl.CustomerImpl
Generating
/TargetProject/com/example/customer/sdo/impl/CustomerImpl.java
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 26 source files to
D:\T\java\sca\itest\properties\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[29,22]
package javax.xml.bind does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[30,33]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[31,33]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[31,33]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[32,33]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[33,33]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[34,33]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[74,11]
cannot find symbol
symbol : class JAXBElement
location: class test.jaxb.props.ObjectFactory
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[49,1]
cannot find symbol
symbol: class XmlRegistry
@XmlRegistry
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[57,1]
cannot find symbol
symbol: class XmlAccessorType
@XmlAccessorType(XmlAccessType.FIELD)
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[58,1]
cannot find symbol
symbol: class XmlType
@XmlType(name = ReturnCodeProperties, namespace =
http://test.sca.jaxb/rcprops;, propOrder = {
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[73,5]
cannot find symbol
symbol : class XmlElementDecl
location: class test.jaxb.props.ObjectFactory
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[64,5]
cannot find symbol
symbol : class XmlElement
location: class test.jaxb.props.ReturnCodeProperties
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ReturnCodeProperties.java:[66,5]
cannot find symbol
symbol : class XmlElement
location: class test.jaxb.props.ReturnCodeProperties
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\package-info.java:[26,26]
package javax.xml.bind.annotation does not exist
D:\T\java\sca\itest\properties\src\main\java\test\jaxb\props\ObjectFactory.java:[75,19]
cannot find symbol
symbol : class JAXBElement
location: class test.jaxb.props.ObjectFactory
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 6 seconds
[INFO] Finished at: Sun Jun 08 14:15:34 IST 2008
[INFO] Final Memory: 14M/26M
[INFO]
Re: RuntimeException: no data binding for null with binding.ws when the service inteface uses generics
Done. TUSCANY-2373. ++Vamsi On Fri, Jun 6, 2008 at 4:46 PM, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: I have the following method in my service interface that uses binding.ws: T Bean1T getTypeUnbound(T[] anArray); I am getting the following exception in SCADomain.newInstance() Please open a JIRA for this, with a test case. Simon org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237) ... 18 more Caused by: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47) at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982) ... 19 more I get a similar exception when I add a method Object getNewObject(Object obj) to my service interface. IIRC, this used to work 10 days ago! ++Vamsi ++Vamsi
[jira] Updated: (TUSCANY-2373) RuntimeException: no data binding for null with binding.ws when the service interface uses generics
[ https://issues.apache.org/jira/browse/TUSCANY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2373: - Attachment: TUSCANY-2373-testcase.patch TUSCANY-2373-testcase.patch: A testcase for the JIRA. After applying the patch, build itest/databindings/temp RuntimeException: no data binding for null with binding.ws when the service interface uses generics - Key: TUSCANY-2373 URL: https://issues.apache.org/jira/browse/TUSCANY-2373 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2373-testcase.patch I have the following method in my service interface that uses binding.ws: T Bean1T getTypeUnbound(T[] anArray); I am getting the following exception in SCADomain.newInstance() org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237) ... 18 more Caused by: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47
RuntimeException: no data binding for null with binding.ws when the service inteface uses generics
I have the following method in my service interface that uses binding.ws: T Bean1T getTypeUnbound(T[] anArray); I am getting the following exception in SCADomain.newInstance() org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237) ... 18 more Caused by: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47) at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982) ... 19 more I get a similar exception when I add a method Object getNewObject(Object obj) to my service interface. IIRC, this used to work 10 days ago! ++Vamsi ++Vamsi
[jira] Created: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1] [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2371: - Description: Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope was: Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1] [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope Assignee: Vamsavardhana Reddy Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2371: - Attachment: TUSCANY-2371.patch TUSCANY-2371.patch: Adds tests for standard types Notes: 1. Tests related to java.lang.Object are not added since it is resulting in java.lang.RuntimeException: no data binding for null. 2. Tests related to javax.xml.transform.Source are not added since it is resulting in java.lang.RuntimeException: no data binding for javax.xml.transform.Source. 3. Tests related to the following are marked @Ignore since the tests are failing. binding.sca: URI array, Image array, DataHandler, DataHandler array binding.ws: QName array, URI, URI array, Image, Image array, DataHandler, DataHandler array Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2371.patch Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Databinding integration tests
On Thu, Jun 5, 2008 at 3:00 AM, Raymond Feng [EMAIL PROTECTED] wrote: The wiki page is very nice. Thanks. A quick update, the byte[] support is now in place and the test case is passing in SVN. The jaxws-maven-plugin is generating the following types for byte[] : xs:complexType name=negateByteArray xs:sequence xs:element name=arg0 type=xs:base64Binary nillable=true minOccurs=0/ /xs:sequence /xs:complexType xs:complexType name=negateByteArrayResponse xs:sequence xs:element name=return type=xs:base64Binary nillable=true minOccurs=0/ /xs:sequence /xs:complexType Whereas ?wsdl is generating the type: xs:element name=negateByteArray xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true type=xs:byte/ /xs:sequence /xs:complexType /xs:element ++Vamsi Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 11:09 AM To: tuscany-dev@ws.apache.org Subject: Databinding integration tests Hi, I have been developing some databinding integration tests recently. The scope and status of this exercise is maintained in Tuscany wiki at [1]. The tests developed so far are under sca\itest\databinding\jaxb-bottom-up [2]. Please provide comments, suggestions on the scope, anything missing, any improvements to the code already in svn, etc. so that we have a good test coverage. Thanks, Vamsi [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up
sca/tools/eclipse/plugins/core/.classpath file in svn
Hi, There is a .classpath file in svn at [1]. I guess it made into svn by accident. Can someone remove this file? Each time I try to create a patch, this file shows up in the diffs and I have to manual remove it from the patch files :(. ++Vamsi [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/core/.classpath
Re: [Vote] Release Tuscany Java SCA 1.2.1 (RC1)
+1 ++Vamsi On Mon, Jun 2, 2008 at 2:40 AM, ant elder [EMAIL PROTECTED] wrote: Please review and vote on the release artifacts for the Tuscany SCA for Java 1.2.1 maintenance release. The artifacts are available for review at: http://people.apache.org/~antelder/tuscany/1.2.1-RC1/http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/ http://people.apache.org/%7Eantelder/tuscany/1.2.1-RC1/ This includes the signed binary and source distributions, Maven staging repository, and eclipse update site. The SVN tag for the release is: http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1 The _only_ code change in this over the 1.2 release is in r657526 [1], all other changes are just version updates and doc changes for the release. +1 to release from me. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL PROTECTED]
Strange problem with Calendar comparison
While writing databinding tests for java.util.Calendar type, I have hit a strange problem with comparing Calendar objects. The problem occurs only when using binding.ws to invoke the service method. Even in the problematic case, expected.toString() and actual.toString() are equal but expected.equals(actual) returns false!! Here is an excerpt from the FailureTrace: expected:java.util.GregorianCalendar[time=1212745401890,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id=GMT+05:30,offset=1980,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2008,MONTH=5,WEEK_OF_YEAR=23,WEEK_OF_MONTH=1,DAY_OF_MONTH=6,DAY_OF_YEAR=158,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=3,HOUR_OF_DAY=15,MINUTE=13,SECOND=21,MILLISECOND=890,ZONE_OFFSET=1980,DST_OFFSET=0] but was:java.util.GregorianCalendar[time=1212745401890,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id=GMT+05:30,offset=1980,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2008,MONTH=5,WEEK_OF_YEAR=23,WEEK_OF_MONTH=1,DAY_OF_MONTH=6,DAY_OF_YEAR=158,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=3,HOUR_OF_DAY=15,MINUTE=13,SECOND=21,MILLISECOND=890,ZONE_OFFSET=1980,DST_OFFSET=0] Any ideas what could be wrong? ++Vamsi
[jira] Created: (TUSCANY-2366) QName with just a localPart not getting passed in arrays with binding.ws to invoke service
QName with just a localPart not getting passed in arrays with binding.ws to invoke service -- Key: TUSCANY-2366 URL: https://issues.apache.org/jira/browse/TUSCANY-2366 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I have a service method that takes an array of QName and returns an array of QName. I am noticing that when I invoke the method using webservice binding, the QName elements with just the localPart are not getting passed over the wire. To give an idea of what is happening, I have the following QName array: QName[] qnames = new QName[4]; qnames[0] = new QName(localPart); qnames[1] = new QName(namespaceUri, localPart); qnames[2] = new QName(namespaceUri, localPart, prefix); qnames[3] = new QName(localPart2); When the method is invoked, it is receiving an array with only two elements instead of four. The first and last element that have only the localpart are not getting passed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests
Databinding tests for primitives and primitive arrays - local service, pass-by-value tests -- Key: TUSCANY-2361 URL: https://issues.apache.org/jira/browse/TUSCANY-2361 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next TUSCANY-2350 added databinding tests for primitives and primitive arrays using a remotable service. The same tests need to be done for a local service too (see [1]). Also, the pass-by-value semantics does not seem to be working for byte array. It is a good idea to add tests for pass-by-value for byte array and arrays of other primitive types. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests
[ https://issues.apache.org/jira/browse/TUSCANY-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2361: - Attachment: TUSCANY-2361.patch TUSCANY-2361.patch: 1. Refactored the implementation to provide both local and remotable services. 2. Adds tests for local service 3. Adds tests for pass-by-value for remotable service with binding.sca and binding.ws Databinding tests for primitives and primitive arrays - local service, pass-by-value tests -- Key: TUSCANY-2361 URL: https://issues.apache.org/jira/browse/TUSCANY-2361 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2361.patch TUSCANY-2350 added databinding tests for primitives and primitive arrays using a remotable service. The same tests need to be done for a local service too (see [1]). Also, the pass-by-value semantics does not seem to be working for byte array. It is a good idea to add tests for pass-by-value for byte array and arrays of other primitive types. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests
[ https://issues.apache.org/jira/browse/TUSCANY-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2361: - Patch Info: [Patch Available] Databinding tests for primitives and primitive arrays - local service, pass-by-value tests -- Key: TUSCANY-2361 URL: https://issues.apache.org/jira/browse/TUSCANY-2361 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2361.patch TUSCANY-2350 added databinding tests for primitives and primitive arrays using a remotable service. The same tests need to be done for a local service too (see [1]). Also, the pass-by-value semantics does not seem to be working for byte array. It is a good idea to add tests for pass-by-value for byte array and arrays of other primitive types. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer
Thank you for this great news. And thanks to Tuscany PMC for this recognition. ++Vamsi On Mon, Jun 2, 2008 at 11:32 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany committer. Congratulations and welcome! ...ant
Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer
Hi Ant, Forgot to mention in my previous note... I accept Tuscany PMC's invitation to me to become a committer :) I already have a signed ICLA in place. My JIRA userid is vamsic. My Apache userid is vamsic007. Please add my id to the required groups so that I get the necessary permissions. Thanks and best regards, Vamsi On Mon, Jun 2, 2008 at 11:32 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany committer. Congratulations and welcome! ...ant
Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter
I have a service operation String[][] getGreetingsArray2(String[][] names). I am using interface.java in my service element in the composite. When the service uses a webservice binding, I get the following wsdl using ?wsdl on the endpoint url. wsdl:definitions wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://jaxb.databindings.itest.sca.tuscany.apache.org/; xmlns:ns0=http://util.java/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:element name=getGreetingsArray2 xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsArray2Response xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element ... /xs:schema /wsdl:types /wsdl:definitions Notice that the types correspond to String[] and not String[][]. I have added @WebMethod public String[][] getGreetingsArray2(String[][] names) to MyServiceImpl class in sca\modules\interface-java-jaxws and used jaxws-maven-plugin to generate the wsdl. MyServiceImplService.wsdl has types xsd:schema xsd:import namespace= http://jaxws.java.interfacedef.sca.tuscany.apache.org/; schemaLocation=MyServiceImplService_schema1.xsd/ /xsd:schema xsd:schema xsd:import namespace=http://jaxb.dev.java.net/array; schemaLocation=MyServiceImplService_schema2.xsd/ /xsd:schema /types MyServiceImplService_schema2.xsd has xs:complexType name=stringArray final=#all xs:sequence xs:element name=item type=xs:string minOccurs=0 maxOccurs=unbounded nillable=true/ /xs:sequence /xs:complexType MyServiceImplService_schema1.xsd has xs:complexType name=getGreetingsArray2 xs:sequence xs:element name=arg0 type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType xs:complexType name=getGreetingsArray2Response xs:sequence xs:element name=return type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType In other words jaxws-maven-plugin seems to generate proper types for String[][]. There seems to be a problem with the code that generates wsdl when ?wsdl is used on the endpoint url. ++Vamsi
[jira] Created: (TUSCANY-2356) Databinding itests for Local service
Databinding itests for Local service Key: TUSCANY-2356 URL: https://issues.apache.org/jira/browse/TUSCANY-2356 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding itests added by TUSCANY-2340 deal with only @Remotable service. This JIRA is for itests for Local service. See [1]. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2356) Databinding itests for Local service
[ https://issues.apache.org/jira/browse/TUSCANY-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2356: - Attachment: TUSCANY-2356.patch TUSCANY-2356.patch: Adds tests for Local service. Also a little bit of refactoring to: 1. Have a single component provide both local and remotable service 2. Have the client components to invoke local and remotable services share some of the implementation. Databinding itests for Local service Key: TUSCANY-2356 URL: https://issues.apache.org/jira/browse/TUSCANY-2356 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2356.patch Databinding itests added by TUSCANY-2340 deal with only @Remotable service. This JIRA is for itests for Local service. See [1]. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter
Done. TUSCANY-2358. ++Vamsi On Sat, May 31, 2008 at 3:07 AM, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: I have a service operation String[][] getGreetingsArray2(String[][] names). I am using interface.java in my service element in the composite. When the service uses a webservice binding, I get the following wsdl using ?wsdl on the endpoint url. wsdl:definitions wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://jaxb.databindings.itest.sca.tuscany.apache.org/; xmlns:ns0=http://util.java/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:element name=getGreetingsArray2 xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsArray2Response xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element ... /xs:schema /wsdl:types /wsdl:definitions Notice that the types correspond to String[] and not String[][]. I have added @WebMethod public String[][] getGreetingsArray2(String[][] names) to MyServiceImpl class in sca\modules\interface-java-jaxws and used jaxws-maven-plugin to generate the wsdl. MyServiceImplService.wsdl has types xsd:schema xsd:import namespace= http://jaxws.java.interfacedef.sca.tuscany.apache.org/; schemaLocation=MyServiceImplService_schema1.xsd/ /xsd:schema xsd:schema xsd:import namespace=http://jaxb.dev.java.net/array; schemaLocation=MyServiceImplService_schema2.xsd/ /xsd:schema /types MyServiceImplService_schema2.xsd has xs:complexType name=stringArray final=#all xs:sequence xs:element name=item type=xs:string minOccurs=0 maxOccurs=unbounded nillable=true/ /xs:sequence /xs:complexType MyServiceImplService_schema1.xsd has xs:complexType name=getGreetingsArray2 xs:sequence xs:element name=arg0 type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType xs:complexType name=getGreetingsArray2Response xs:sequence xs:element name=return type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType In other words jaxws-maven-plugin seems to generate proper types for String[][]. There seems to be a problem with the code that generates wsdl when ?wsdl is used on the endpoint url. ++Vamsi This support is not yet implemented in the new runtime Java2WSDL mapping code. Please open a JIRA for this and I will look at it. Thanks. Simon
[jira] Created: (TUSCANY-2358) Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter
Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter --- Key: TUSCANY-2358 URL: https://issues.apache.org/jira/browse/TUSCANY-2358 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I have a service operation String[][] getGreetingsArray2(String[][] names). I am using interface.java in my service element in the composite. When the service uses a webservice binding, I get the following wsdl using ?wsdl on the endpoint url. wsdl:definitions wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace=http://jaxb.databindings.itest.sca.tuscany.apache.org/; xmlns:ns0=http://util.java/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:element name=getGreetingsArray2 xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsArray2Response xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element ... /xs:schema /wsdl:types /wsdl:definitions Notice that the types correspond to String[] and not String[][]. I have added @WebMethod public String[][] getGreetingsArray2(String[][] names) to MyServiceImpl class in sca\modules\interface-java-jaxws and used jaxws-maven-plugin to generate the wsdl. MyServiceImplService.wsdl has types xsd:schema xsd:import namespace=http://jaxws.java.interfacedef.sca.tuscany.apache.org/; schemaLocation=MyServiceImplService_schema1.xsd/ /xsd:schema xsd:schema xsd:import namespace=http://jaxb.dev.java.net/array; schemaLocation=MyServiceImplService_schema2.xsd/ /xsd:schema /types MyServiceImplService_schema2.xsd has xs:complexType name=stringArray final=#all xs:sequence xs:element name=item type=xs:string minOccurs=0 maxOccurs=unbounded nillable=true/ /xs:sequence /xs:complexType MyServiceImplService_schema1.xsd has xs:complexType name=getGreetingsArray2 xs:sequence xs:element name=arg0 type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType xs:complexType name=getGreetingsArray2Response xs:sequence xs:element name=return type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType In other words jaxws-maven-plugin seems to generate proper types for String[][]. There seems to be a problem with the code that generates wsdl when ?wsdl is used on the endpoint url. See http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg32014.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2349) TransformationException when invoking a method with byte array paramter using webservice binding
TransformationException when invoking a method with byte array paramter using webservice binding Key: TUSCANY-2349 URL: https://issues.apache.org/jira/browse/TUSCANY-2349 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy I have a service method that takes a byte array as parameter and returns a byte array. When I invoke the method using webservice binding, I am getting a TransformationException: No path found for the transformation: java:simpleType-java:array. The stacktrace is given below: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:simpleType-java:array at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:163) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:67) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:152) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.negateByteArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.PrimitivesServiceClientImpl.negateByteArrayForward(PrimitivesServiceClientImpl.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:110) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.negateByteArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.performTestNegateByteArray(PrimitivesDatabindingTestCase.java:372) at org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.testWSNegateByteArray(PrimitivesDatabindingTestCase.java:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
[jira] Created: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types
Databinding tests for primitive types and array of primitive types -- Key: TUSCANY-2350 URL: https://issues.apache.org/jira/browse/TUSCANY-2350 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding tests for primitive types and array of primitive types -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2351) byte array passed by reference when using sca binding even though implementation does not have @AllowsPassByReference
byte array passed by reference when using sca binding even though implementation does not have @AllowsPassByReference - Key: TUSCANY-2351 URL: https://issues.apache.org/jira/browse/TUSCANY-2351 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I have method (in a remotable interface) that takes a byte array parameter and returns a byte array. When I invoke the method using SCA binding, I am noticing that the parameter passed to the method is modified even though the implementation is not annotated with @AllowsPassByReference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types
[ https://issues.apache.org/jira/browse/TUSCANY-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2350: - Attachment: TUSCANY-2350.patch TUSCANY-2350.patch: Databinding itests for primitive types and array of primitive types. The test methods related to byte array are maked with @Ignore. See TUSCANY-2349 and TUSCANY-2351. Databinding tests for primitive types and array of primitive types -- Key: TUSCANY-2350 URL: https://issues.apache.org/jira/browse/TUSCANY-2350 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2350.patch Databinding tests for primitive types and array of primitive types -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
TransformationException when using a two dimensional String array as parameter and return value of a service operation invoked with ws binding
Hi, I have a service operation that takes String[][] as parameter and returns a String[][]. When the operation is invoked using a webservice binding, I am getting a TransformationException. The stacktrace is given below. org.apache.tuscany.sca.databinding.TransformationException: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:array-org.apache.axiom.om.OMElement at org.apache.tuscany.sca.core.databinding.transformers.Array2ArrayTransformer.transform(Array2ArrayTransformer.java:106) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:152) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy22.getGreetingsArray2(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.HelloServiceSimpleClientImpl.getGreetingsArray2Forward(HelloServiceSimpleClientImpl.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:110) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy21.getGreetingsArray2Forward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.DatabindingTestCase.performTestArray2(DatabindingTestCase.java:222) at org.apache.tuscany.sca.itest.databindings.jaxb.DatabindingTestCase.testWSArray2(DatabindingTestCase.java:159) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:array-org.apache.axiom.om.OMElement at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:163) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:67) at org.apache.tuscany.sca.core.databinding.transformers.Array2ArrayTransformer.transform(Array2ArrayTransformer.java:100) ... 41 more Can someone tell me if we need
Build failure in sca\modules\databinding-jaxb
Hi,
I am hitting a build failure in sca\modules\databinding-jaxb. Can someone
help? The console output is given below.
++Vamsi
[INFO]
-
---
[INFO] Building Apache Tuscany SCA Data Binding for JAXB
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking
for up
dates from java.net2
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for
upda
tes from java.net2
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: javax.xml.bind:jaxb-api:2.1:jar
[INFO] javax.xml.bind:jaxb-api:2.1:jar already exists in
D:\T\java\sca\modules\d
atabinding-jaxb\target\endorsed
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory:
D:\T\java\sca\modules\databinding-jaxb\target\jaxb
-source added.
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from java.net
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from apache.incubator
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from indiana
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from osuosl.org
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from java.net
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from apache.incubator
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from indiana
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from osuosl.org
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from apache.snapshots
[INFO] [jaxb2:generate {execution: generate-jaxb}]
[INFO] Skipped XJC execution. Generated sources were up-to-date.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 27 source files to
D:\T\java\sca\modules\databinding-jaxb\targe
t\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
D:\T\java\sca\modules\databinding-jaxb\src\main\java\org\apache\tuscany\sca\data
binding\jaxb\DataConverter.java:[46,20] package javax.xml.ws does not exist
D:\T\java\sca\modules\databinding-jaxb\src\main\java\org\apache\tuscany\sca\data
binding\jaxb\DataConverter.java:[173,69] cannot find symbol
symbol : class WebServiceException
location: class org.apache.tuscany.sca.databinding.jaxb.DataConverter
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 17 seconds
[INFO] Finished at: Fri May 30 09:48:58 IST 2008
[INFO] Final Memory: 15M/28M
[INFO]
Re: Build failure in sca\modules\databinding-jaxb
Has anyone else hit this build error? The error is fixed after adding
dependency
groupIdjavax.xml.ws/groupId
artifactIdjaxws-api/artifactId
version2.1/version
/dependency
to sca\modules\databinding-jaxb\pom.xml.
Is this a required dependency?
++Vamsi
On Fri, May 30, 2008 at 9:52 AM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Hi,
I am hitting a build failure in sca\modules\databinding-jaxb. Can someone
help? The console output is given below.
++Vamsi
[INFO]
-
---
[INFO] Building Apache Tuscany SCA Data Binding for JAXB
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking
for up
dates from java.net2
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for
upda
tes from java.net2
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: javax.xml.bind:jaxb-api:2.1:jar
[INFO] javax.xml.bind:jaxb-api:2.1:jar already exists in
D:\T\java\sca\modules\d
atabinding-jaxb\target\endorsed
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory:
D:\T\java\sca\modules\databinding-jaxb\target\jaxb
-source added.
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from java.net
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from apache.incubator
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from indiana
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from osuosl.org
[INFO] snapshot
org.apache.tuscany.sca:tuscany-modules:2.0-incubating-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from java.net
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from apache.incubator
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from indiana
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from osuosl.org
[INFO] snapshot org.apache.tuscany.sca:tuscany-sca:2.0-incubating-SNAPSHOT:
chec
king for updates from apache.snapshots
[INFO] [jaxb2:generate {execution: generate-jaxb}]
[INFO] Skipped XJC execution. Generated sources were up-to-date.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 27 source files to
D:\T\java\sca\modules\databinding-jaxb\targe
t\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
D:\T\java\sca\modules\databinding-jaxb\src\main\java\org\apache\tuscany\sca\data
binding\jaxb\DataConverter.java:[46,20] package javax.xml.ws does not
exist
D:\T\java\sca\modules\databinding-jaxb\src\main\java\org\apache\tuscany\sca\data
binding\jaxb\DataConverter.java:[173,69] cannot find symbol
symbol : class WebServiceException
location: class org.apache.tuscany.sca.databinding.jaxb.DataConverter
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 17 seconds
[INFO] Finished at: Fri May 30 09:48:58 IST 2008
[INFO] Final Memory: 15M/28M
[INFO]
Re: TransformationException when using java interface definition with generics
Don't know what changed in these three days, but, it is working now :)
++Vamsi
On Sat, May 24, 2008 at 4:49 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Attached generics-problem.patch to recreate the problem.
++Vamsi
On Sat, May 24, 2008 at 4:30 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
On Fri, May 23, 2008 at 11:53 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
It's not clear from the SCA spec how generics impacts the interface
mapping. We need some clarifications there.
The JAXWS 2.1 spec uses the erased type and only honor the type argument
in Collection. At this moment, Tuscany supports the following case:
@Remotable
public interface MyHelloService extends HelloServiceString {
}
And use MyHelloService as the service interface for HelloServiceImpl.
Hmm... I tried this part and it does not seem to work.
SCADomain.newInstance() is throwing an exception. Stack trace given below:
org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.NullPointerException
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.itest.DatabindingTestCase.setUp(DatabindingTestCase.java:39)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.NullPointerException
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 16 more
Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.NullPointerException
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237)
... 18 more
Caused by: java.lang.NullPointerException
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:212)
at
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:246)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:56)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:66)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:46)
at
org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982)
... 19 more
I don't think it's wise to try to cover other variations before we get it
clarified by the spec.
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Friday, May 23, 2008 10:42 AM
To: tuscany-dev@ws.apache.org
Subject: TransformationException when using java interface definition
with generics
Can someone point to me what I am doing wrong or if it is a problem in
Tuscany
Re: TransformationException when using java interface definition with generics
On Fri, May 23, 2008 at 11:53 PM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
It's not clear from the SCA spec how generics impacts the interface
mapping. We need some clarifications there.
The JAXWS 2.1 spec uses the erased type and only honor the type argument in
Collection. At this moment, Tuscany supports the following case:
@Remotable
public interface MyHelloService extends HelloServiceString {
}
And use MyHelloService as the service interface for HelloServiceImpl.
Hmm... I tried this part and it does not seem to work.
SCADomain.newInstance() is throwing an exception. Stack trace given below:
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.NullPointerException
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.itest.DatabindingTestCase.setUp(DatabindingTestCase.java:39)
at junit.framework.TestCase.runBare(TestCase.java:132)
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.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.NullPointerException
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 16 more
Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.NullPointerException
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237)
... 18 more
Caused by: java.lang.NullPointerException
at
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.getOperation(WSDLOperationIntrospectorImpl.java:212)
at
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:246)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:56)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:66)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:46)
at
org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982)
... 19 more
I don't think it's wise to try to cover other variations before we get it
clarified by the spec.
Thanks,
Raymond
--
From: Vamsavardhana Reddy [EMAIL PROTECTED]
Sent: Friday, May 23, 2008 10:42 AM
To: tuscany-dev@ws.apache.org
Subject: TransformationException when using java interface definition with
generics
Can someone point to me what I am doing wrong or if it is a problem in
Tuscany? Details follow...
I have the following service interface:
@Remotable
public interface HelloServiceE {
public E getGreetings(E name);
}
The following is the service implementation:
@Service(HelloService.class)
public class HelloServiceImpl implements HelloServiceString {
public String getGreetings(String name) {
return Hello +name
Problem building sca\modules\interface-java-jaxws with jaxws-maven-plugin uncommented in pom.xml
I have uncommented the jaxws-maven-plugin in
sca\modules\interface-java-jaxws\pom.xml. The following is the xml
fragment:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjaxws-maven-plugin/artifactId
version1.9/version
configuration
seiorg.apache.tuscany.sca.interfacedef.java.jaxws.MyServiceImpl/sei
genWsdltrue/genWsdl
/configuration
executions
execution
phaseprocess-test-classes/phase
goals
goalwsgen-test/goal
/goals
/execution
/executions
/plugin
Upon building the project, I am hitting a build error. The following is the
output in command window when the build is run with stacktraces on:
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] Building Apache Tuscany Java Interface for JAXWS
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory D:\T\java\sca\modules\interface-java-jaxws\target
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: javax.xml.ws:jaxws-api:2.1:jar
[INFO] Configured Artifact: javax.xml.bind:jaxb-api:2.1:jar
[INFO] Copying jaxws-api-2.1.jar to
D:\T\java\sca\modules\interface-java-jaxws\target\endorsed\jaxws-api-2.1.jar
[INFO] Copying jaxb-api-2.1.jar to
D:\T\java\sca\modules\interface-java-jaxws\target\endorsed\jaxb-api-2.1.jar
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory:
D:\T\java\sca\modules\interface-java-jaxws\target\jaxws-source added.
[INFO] [jaxws:wsimport {execution: default}]
[INFO] Processing:
D:\T\java\sca\modules\interface-java-jaxws\src\test\resources\wsdl\StockExceptionTest.wsdl
[INFO] jaxws:wsimport args: [-s,
D:\T\java\sca\modules\interface-java-jaxws\target\jaxws-source, -d,
D:\T\java\sca\modules\interface-java-jaxws\target\classes, -p,
com.example.stock, -Xnocompile,
D:\T\java\sca\modules\interface-java-jaxws\src\test\resources\wsdl\StockExceptionTest.wsdl]
parsing WSDL...
generating code...
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 13 source files to
D:\T\java\sca\modules\interface-java-jaxws\target\classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 17 source files to
D:\T\java\sca\modules\interface-java-jaxws\target\test-classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] One or more required plugin parameters are invalid/missing for
'jaxws:wsgen-test'
[0] inside the definition for plugin: 'jaxws-maven-plugin'specify the
following:
configuration
...
seiVALUE/sei
/configuration.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring:
org.codehaus.mojo:jaxws-maven-plugin. Reason: Invalid or missing parameters:
[Mojo parameter [name: 'sei'; alias: 'null']] for mojo:
org.codehaus.mojo:jaxws-maven-plugin:1.9:wsgen-test
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:568)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at
TransformationException when using java interface definition with generics
Can someone point to me what I am doing wrong or if it is a problem in
Tuscany? Details follow...
I have the following service interface:
@Remotable
public interface HelloServiceE {
public E getGreetings(E name);
}
The following is the service implementation:
@Service(HelloService.class)
public class HelloServiceImpl implements HelloServiceString {
public String getGreetings(String name) {
return Hello +name;
}
}
The following is the client interface that invokes the service:
public interface HelloServiceClientE {
E getGreetingsForward(E name);
}
The following is the client implementation:
@Service(HelloServiceClient.class)
public class HelloServiceClientImpl implements HelloServiceClientString {
private HelloServiceString service;
@Reference
public void setHelloService(HelloServiceString service) {
this.service = service;
}
public String getGreetingsForward(String name) {
return service.getGreetings(name);
}
}
I have a HelloService component and two HelloServiceClient components in my
composite (given below):
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance;
name=HelloService
!-- Clients to test the service --
component name=HelloServiceClientWSComponent
implementation.java
class=org.apache.tuscany.sca.itest.impl.HelloServiceClientImpl /
reference name=helloService
interface.java
interface=org.apache.tuscany.sca.itest.HelloService/
binding.ws uri=http://localhost:8080/hs-ep1/
/reference
/component
component name=HelloServiceClientSCAComponent
implementation.java
class=org.apache.tuscany.sca.itest.impl.HelloServiceClientImpl /
reference name=helloService target=HelloServiceComponent
binding.sca/
/reference
/component
!-- Components used to implement the services --
component name=HelloServiceComponent
implementation.java
class=org.apache.tuscany.sca.itest.impl.HelloServiceImpl/
service name=HelloService
interface.java
interface=org.apache.tuscany.sca.itest.HelloService/
binding.ws uri=http://localhost:8080/hs-ep1/
binding.sca/
/service
/component
/composite
The following is the code I am using to invoke the service via client
components:
domain = SCADomain.newInstance(hello.composite);
String name = Me String SCA;
HelloServiceClientString helloServiceClient =
domain.getService(HelloServiceClient.class,
HelloServiceClientSCAComponent);
String resp = helloServiceClient.getGreetingsForward(name);
System.out.println(resp);
name = Me String WS;
helloServiceClient = domain.getService(HelloServiceClient.class,
HelloServiceClientWSComponent);
resp = helloServiceClient.getGreetingsForward(name);
System.out.println(resp);
It works fine when I invoke the service using the client component that uses
SCA binding to connect to the service. I get the following exception when I
use the client component that uses WS binding.
May 23, 2008 11:04:50 PM
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver
invokeBusinessLogic
SEVERE: org.apache.tuscany.sca.databinding.TransformationException: No path
found for the transformation: org.apache.axiom.om.OMElement-null
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.databinding.TransformationException: No path found
for the transformation: org.apache.axiom.om.OMElement-null
at
org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:119)
at
org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:85)
at
org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:79)
at
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWireImpl.java:138)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:669)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:68)
at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
Re: Graduation
That's great news. ++Vamsi On Thu, May 22, 2008 at 2:44 AM, Matthieu Riou [EMAIL PROTECTED] wrote: Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present. Congratulations guys! Matthieu
[jira] Updated: (TUSCANY-2311) Second equivalently typed callback field not injected
[ https://issues.apache.org/jira/browse/TUSCANY-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2311: - Attachment: TUSCANY-2311.patch TUSCANY-2311.patch: Fixing this problem requires changing the JavaImplementation interface i.e., JavaImplementation.getCallbackMembers() to return MapString, CollectionJavaElementImpl instead of MapString, JavaElementImpl. I have verified that this patch does not break the build. The patch can use a thorough review to see if the changes in JavaComponentContextProvider and OSGiPropertyInjector can be optimized to reuse the ObjectFactory. Second equivalently typed callback field not injected - Key: TUSCANY-2311 URL: https://issues.apache.org/jira/browse/TUSCANY-2311 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Attachments: TUSCANY-2311.patch The Java CAA specification states on lines 670-671: 670 If a single callback has a type that is compatible with multiple declared callback fields, then all of them will 671 be set. The test org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statefulMultiBidirectional() demonstrates that a second annotated field with the same type is not injected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2311) Second equivalently typed callback field not injected
[ https://issues.apache.org/jira/browse/TUSCANY-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2311: - Patch Info: [Patch Available] Assignee: (was: Vamsavardhana Reddy) Unassigning so that a committer can pickup. Second equivalently typed callback field not injected - Key: TUSCANY-2311 URL: https://issues.apache.org/jira/browse/TUSCANY-2311 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Attachments: TUSCANY-2311.patch The Java CAA specification states on lines 670-671: 670 If a single callback has a type that is compatible with multiple declared callback fields, then all of them will 671 be set. The test org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statefulMultiBidirectional() demonstrates that a second annotated field with the same type is not injected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Conversational semantics using xml in SCDLs
On Thu, May 15, 2008 at 2:32 PM, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: Right now all the conversation related things we have in Tuscany seem to use annotations in Java code. The assembly schema does not seem to be good enough to specify the equivalents through SCDLs. Here are some of the issues, taking the java annotations as a reference point, that are coming in the way of conversational semantics using SCDLs. I would like to hear from others before I take up these with OASIS SCA Assembly TC. So, please provide your input and also suggest any aspects that I may be missing to see. 1. Designating an interface as conversational: JAVA: The @Conversational annotation used to designate a Java interface as conversational. Wherever the interface is used, it is seen as conversational interface consistently. ASSEMBLY: I do not see a way to designate an interface (just the interface definition) as conversational through SCDLs. This was resolved by http://www.osoa.org/jira/browse/ASSEMBLY-47. Either the interface can be annotated as conversational, or the service or reference using the interface can be annotated as converational. By designating just the interface as conversational, I meant it should be considered as conversational wherever it appears in the SCDLs without having to specify anything additional. I think with ASSEMBLY-47 only the service or reference under which the interface element appears will be considered as conversational and it does not affect the other occurrences of the same interface elsewhere in the composite. For example in: component name=c1 ... service name=Service1 interface.java interface=MyService requires=conversational operation name=method1 endsConversation=true/ /interface.java /service /component component name=c2 ... service name=Service1 interface.java interface=MyService/ /service /component The MyService interface is conversational only in component c1 but not in c2. 2. Designating a method in a conversational interface as ends conversation. JAVA: The @EndsConversation annotation on a method designates the method as ends conversation. ASSEMBLY: Right now there is no way to do this through SCDLs. http://www.osoa.org/jira/browse/ASSEMBLY-47 seem to talk about a similar issue but in the context of interfaces defined in WSDLs. Problem: Even if an operation element is introduced under interface element, it is not possible to guarantee consistency across all the occurrences of the interface in the SCDLs. For example, the interface used under a service element in component1 may designate method1 as ends conversation where as a different component using the same interface need not necessarily designate method1 as ends conversation. If the two components involved are being wired together using this interface, but have inconsistent definitions for which methods are ends conversation, this is an error in the SCDL assembly and should be detected by the SCA runtime. It is not necessary that both the components are wired together. The two components could be using the interface element under service element. 3. Designating a service is a conversational service: JAVA: A service whose interface is decorated with @Conversational annotation is a conversational service. ASSEMBLY: A conversational intent can be specified on the component service whose java interface is not decorated with @Conversational. Problem: We can not guarantee that all components that provide a service with a particular interface use the conversational intent on the service consistently. For e.g, component1 may use conversational intent on the service1, whereas component2 that provides a service2 with the same interface as service1 need not use conversational intent. Why is this a problem? From SCA's perspective, the conversational and non-conversational forms would be different interfaces. Unless they are wired together, this does not cause any problems. Tuscany seems to use the same interface object wherever an interface features. Perhaps it should clone the interface object so that additional intents can be set as required without affecting all occurrences of the interface. 4. Specifying Conversation attributes: JAVA: The @ConversationAttributes annotation used on the implementation class enables specifying conversation attributes applicable to the conversational interfaces of services and references of the class. ASSEMBLY: Right now there is no way to specify conversation attributes through SCDLs. http://www.osoa.org/jira/browse/JAVA-14 seems to refer to the same problem. Yes it does, so this issue can be used to discuss and create a proposal. 5. Specifying a callback interface for a service interface. JAVA: The @Callback annotation on a service interface specifies the callback interface. ASSEMBLY: Optional callbackInterface attribute on the interface
Re: Conversational semantics using xml in SCDLs
Hi Mike, Thanks for the heads-up. Let us see whether the Assembly TC does the same this time too with the proposal to add a top level interface element. ++Vamsi On Thu, May 15, 2008 at 6:07 PM, Mike Edwards [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: snip For 1, 2, 3 and 5, I think it is a good idea to introduce a new interface definition as a top level element in SCDLs. This new interface definition could use any existing interface definition and add additional semantics. For example, something like interface.xxx name=myConversationalInterface interface=myNonConversationalInterface conversational=true operation name=method1 endsConversation=true/ /interface.xxx can yield a conversational interface myConversationalInterface from a non-conversational interface myNonConversationalInterface. This should work as if there were annotations on the original interface definition. With this new interface definition in place, we may not need conversational intent on service or reference and myConversationalInterface can be used whereever myNonConversationalInterface were to be used along with a conversational intent on the service or reference. Please comment if any of the above does not make sense or suggest any alternative ways to deal with these issues. ++Vamsi snip Vamsi, Simon has given a good comprehensive response to your main points - I would like to focus on this final suggestion. You will meet some substantial opposition in the spec group to the idea of creating a new SCDL-based interface definition language. The group has rejected such suggestions more than once in the past. The argument is that there are already very good interface definition languages available - and that where SCA extensions are necessary, they can be added as extension annotations to those existing languages. Providing yet another parallel interface definition language simply adds to the complexity of SCA without a corresponding benefit. I believe that all the issues you raise are already covered by the specs - or there are open issues awaiting resolution. You are welcome to make suggestions to the SCA specification group, of course, but I thought it useful to give you a heads-up on the likely reaction. Yours, Mike.
[jira] Created: (TUSCANY-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces
Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces Key: TUSCANY-2323 URL: https://issues.apache.org/jira/browse/TUSCANY-2323 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am getting an error with generating wsdl using ?wsdl on the url for webservice when the original wsdl file used to specify the service interface does not use soap namespaces. The following is the wsdl file: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://helloworld; xmlns:tns=http://helloworld; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=helloworld wsdl:types schema elementFormDefault=qualified targetNamespace=http://helloworld; xmlns=http://www.w3.org/2001/XMLSchema; element name=getGreetings complexType sequence element name=name type=xsd:string/ /sequence /complexType /element element name=getGreetingsResponse complexType sequence element name=getGreetingsReturn type=xsd:string/ /sequence /complexType /element /schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetingsResponse name=parameters/ /wsdl:message wsdl:portType name=HelloWorld wsdl:operation name=getGreetings wsdl:input message=tns:getGreetingsRequest name=getGreetingsRequest/ wsdl:output message=tns:getGreetingsResponse name=getGreetingsResponse/ /wsdl:operation /wsdl:portType /wsdl:definitions The following is the composite: ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws uri=http://localhost:8085/HelloWorldService/ /service /component /composite The error I am seeing is given below: May 16, 2008 12:13:52 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet /HelloWorldService threw exception org.apache.axis2.AxisFault: WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://schemas.xmlsoap.org/wsdl/soap/'. Namespace prefixes must be set on the Definition object using the addNamespace(...) method. at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at org.apache.axis2.description.AxisService.printUserWSDL(AxisService.java:936) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1056) at org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:142) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:354
[jira] Updated: (TUSCANY-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces
[ https://issues.apache.org/jira/browse/TUSCANY-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2323: - Attachment: TUSCANY-2323-recreate.patch TUSCANY-2323-recreate.patch: To recreate the problem, apply this patch and build the helloworld-ws-service sample. testWsdlGeneration() test hits a error with the above mentioned exception. Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces Key: TUSCANY-2323 URL: https://issues.apache.org/jira/browse/TUSCANY-2323 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2323-recreate.patch I am getting an error with generating wsdl using ?wsdl on the url for webservice when the original wsdl file used to specify the service interface does not use soap namespaces. The following is the wsdl file: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://helloworld; xmlns:tns=http://helloworld; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=helloworld wsdl:types schema elementFormDefault=qualified targetNamespace=http://helloworld; xmlns=http://www.w3.org/2001/XMLSchema; element name=getGreetings complexType sequence element name=name type=xsd:string/ /sequence /complexType /element element name=getGreetingsResponse complexType sequence element name=getGreetingsReturn type=xsd:string/ /sequence /complexType /element /schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetingsResponse name=parameters/ /wsdl:message wsdl:portType name=HelloWorld wsdl:operation name=getGreetings wsdl:input message=tns:getGreetingsRequest name=getGreetingsRequest/ wsdl:output message=tns:getGreetingsResponse name=getGreetingsResponse/ /wsdl:operation /wsdl:portType /wsdl:definitions The following is the composite: ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws uri=http://localhost:8085/HelloWorldService/ /service /component /composite The error I am seeing is given below: May 16, 2008 12:13:52 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet /HelloWorldService threw exception org.apache.axis2.AxisFault: WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://schemas.xmlsoap.org/wsdl/soap/'. Namespace prefixes must be set on the Definition object using the addNamespace(...) method. at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at org.apache.axis2.description.AxisService.printUserWSDL(AxisService.java:936) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1056) at org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:142) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128
[jira] Assigned: (TUSCANY-2311) Second equivalently typed callback field not injected
[ https://issues.apache.org/jira/browse/TUSCANY-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned TUSCANY-2311: Assignee: Vamsavardhana Reddy Second equivalently typed callback field not injected - Key: TUSCANY-2311 URL: https://issues.apache.org/jira/browse/TUSCANY-2311 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy The Java CAA specification states on lines 670-671: 670 If a single callback has a type that is compatible with multiple declared callback fields, then all of them will 671 be set. The test org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statefulMultiBidirectional() demonstrates that a second annotated field with the same type is not injected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TUSCANY-1867) @OneWay with String return type causes NullPointerException
[ https://issues.apache.org/jira/browse/TUSCANY-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reopened TUSCANY-1867: -- r656190 is causing build failures in samples\callback-ws-service because @OneWay annotation is present on org.apache.tuscany.sca.node.management.SCANodeManagerService.destroyNode(). And the message in the exception is not really helpful if it does not tell what is the problematic method carrying the @OneWay annotation. @OneWay with String return type causes NullPointerException --- Key: TUSCANY-1867 URL: https://issues.apache.org/jira/browse/TUSCANY-1867 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows XP Reporter: Simon Nash Assignee: ant elder Fix For: Java-SCA-Next Attachments: TUSCANY-1867.patch I tried using @OneWay on a method with a String return type and I got a NullPointerException, like this: Exception in thread Axis2 Task java.lang.NullPointerException at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:444) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) We should produce a better exception to tell the user what he/she has done wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-1867) @OneWay with String return type causes NullPointerException
[ https://issues.apache.org/jira/browse/TUSCANY-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-1867: - Attachment: TUSCANY-1867-2.patch TUSCANY-1867-2.patch: Fixes SCANodeManagerService.destroyNode(). @OneWay with String return type causes NullPointerException --- Key: TUSCANY-1867 URL: https://issues.apache.org/jira/browse/TUSCANY-1867 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Environment: Windows XP Reporter: Simon Nash Assignee: ant elder Fix For: Java-SCA-Next Attachments: TUSCANY-1867-2.patch, TUSCANY-1867.patch I tried using @OneWay on a method with a String return type and I got a NullPointerException, like this: Exception in thread Axis2 Task java.lang.NullPointerException at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:444) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) We should produce a better exception to tell the user what he/she has done wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2248) SOAP intents not being honored
[ https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2248: - Attachment: TUSCANY-2248.patch TUSCANY-2248.patch: Takes care of converting soap11 and soap12 to the qualified forms soap.1_1 and soap.1_2. SOAP intents not being honored Key: TUSCANY-2248 URL: https://issues.apache.org/jira/browse/TUSCANY-2248 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Reporter: Lou Amodeo Fix For: Java-SCA-Next Attachments: TUSCANY-2248.patch Hi, It looks like there are a couple issues with the handling of the SOAP version intents with the Web Services binding. The first one is the literal used to identify the SOAP version and the second is the alrogitym used to apply the SOAP intent. 1) Tuscany is currently using soap. soap11 and soap12 for the literals to identify the soap version. I believe these should be soap, soap.1_1, soap.1_2 according to section 2.3.1 of WS Binding specification. 2) During WSDL generation the soap.1_1 intent is not being honored. It appears that the algorithm to determine which soap version to use is incorrect. I believe it should be as follows: I think this is the algorithym: no requires= specifying a soap version or requires=soap - generate soap.1_1 and soap.1_2 port and binding requires = soap.1_1 - generate soap.1_1 port and binding only requires = soap.1_.2 - generate soap.1_2. port and binding only I also see that an http port/binding is generated by Axis2 by default. Since he intetns are based on soap version I would think the http:address should not be generated. wsdl:port name=HelloWorldServiceHttpEndpoint binding=ns:HelloWorldServiceHttpBinding http:address location=http://localhost:8080/axis2/services/HelloWorldService/ /wsdl:port -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2248) SOAP intents not being honored
[
https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2248:
-
Attachment: TUSCANY-2248-2.patch
TUSCANY-2248-2.patch:
Since soap.1_1 and soap.1_2 are now qualified intents of soap, even though
it seems logical that
sca:bindingType type=sca:binding.ws mayProvide=soap soap11 soap12
alwaysProvides=/
can be replaced with
sca:bindingType type=sca:binding.ws mayProvide=soap alwaysProvides=/
I am hitting some warning messages like the following:
May 13, 2008 3:13:06 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyConfigurationException: The
following are unfulfilled intents for binding in service - ep2
Unfulfilled Intents = [{http://www.osoa.org/xmlns/sca/1.0}soap.1_1]
SOAP intents not being honored
Key: TUSCANY-2248
URL: https://issues.apache.org/jira/browse/TUSCANY-2248
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.0
Reporter: Lou Amodeo
Fix For: Java-SCA-Next
Attachments: TUSCANY-2248-2.patch, TUSCANY-2248.patch
Hi, It looks like there are a couple issues with the handling of the SOAP
version intents with the Web Services binding. The first one is the literal
used to identify the SOAP version and the second is the alrogitym used to
apply the SOAP intent.
1) Tuscany is currently using soap. soap11 and soap12 for the literals to
identify the soap version. I believe these should be soap, soap.1_1,
soap.1_2 according to section 2.3.1 of WS Binding specification.
2) During WSDL generation the soap.1_1 intent is not being honored. It
appears that the algorithm to determine which soap version to use is
incorrect. I believe it should be as follows:
I think this is the algorithym:
no requires= specifying a soap version or requires=soap
- generate soap.1_1 and soap.1_2 port and binding
requires = soap.1_1
- generate soap.1_1 port and binding only
requires = soap.1_.2
- generate soap.1_2. port and binding only
I also see that an http port/binding is generated by Axis2 by default.
Since he intetns are based on soap version I would
think the http:address should not be generated.
wsdl:port name=HelloWorldServiceHttpEndpoint
binding=ns:HelloWorldServiceHttpBinding
http:address
location=http://localhost:8080/axis2/services/HelloWorldService/
/wsdl:port
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TUSCANY-2248) SOAP intents not being honored
[
https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596341#action_12596341
]
vamsic edited comment on TUSCANY-2248 at 5/13/08 3:03 AM:
---
TUSCANY-2248-2.patch:
Since soap.1_1 and soap.1_2 are now qualified intents of soap, even though
it seems logical that
sca:bindingType type=sca:binding.ws mayProvide=soap soap.1_1 soap.1_2
alwaysProvides=/
can be replaced with
sca:bindingType type=sca:binding.ws mayProvide=soap alwaysProvides=/
I am hitting some warning messages like the following:
May 13, 2008 3:13:06 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyConfigurationException: The
following are unfulfilled intents for binding in service - ep2
Unfulfilled Intents = [{http://www.osoa.org/xmlns/sca/1.0}soap.1_1]
was (Author: vamsic):
TUSCANY-2248-2.patch:
Since soap.1_1 and soap.1_2 are now qualified intents of soap, even though
it seems logical that
sca:bindingType type=sca:binding.ws mayProvide=soap soap11 soap12
alwaysProvides=/
can be replaced with
sca:bindingType type=sca:binding.ws mayProvide=soap alwaysProvides=/
I am hitting some warning messages like the following:
May 13, 2008 3:13:06 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Policy related exception:
org.apache.tuscany.sca.assembly.builder.impl.PolicyConfigurationException: The
following are unfulfilled intents for binding in service - ep2
Unfulfilled Intents = [{http://www.osoa.org/xmlns/sca/1.0}soap.1_1]
SOAP intents not being honored
Key: TUSCANY-2248
URL: https://issues.apache.org/jira/browse/TUSCANY-2248
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.0
Reporter: Lou Amodeo
Fix For: Java-SCA-Next
Attachments: TUSCANY-2248-2.patch, TUSCANY-2248.patch
Hi, It looks like there are a couple issues with the handling of the SOAP
version intents with the Web Services binding. The first one is the literal
used to identify the SOAP version and the second is the alrogitym used to
apply the SOAP intent.
1) Tuscany is currently using soap. soap11 and soap12 for the literals to
identify the soap version. I believe these should be soap, soap.1_1,
soap.1_2 according to section 2.3.1 of WS Binding specification.
2) During WSDL generation the soap.1_1 intent is not being honored. It
appears that the algorithm to determine which soap version to use is
incorrect. I believe it should be as follows:
I think this is the algorithym:
no requires= specifying a soap version or requires=soap
- generate soap.1_1 and soap.1_2 port and binding
requires = soap.1_1
- generate soap.1_1 port and binding only
requires = soap.1_.2
- generate soap.1_2. port and binding only
I also see that an http port/binding is generated by Axis2 by default.
Since he intetns are based on soap version I would
think the http:address should not be generated.
wsdl:port name=HelloWorldServiceHttpEndpoint
binding=ns:HelloWorldServiceHttpBinding
http:address
location=http://localhost:8080/axis2/services/HelloWorldService/
/wsdl:port
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
+1 ++Vamsi On Sat, May 10, 2008 at 12:47 PM, ant elder [EMAIL PROTECTED] wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged.
Does Tuscany support WSDL2.0?
I am trying to create a vtest for service binding.ws as part of TUSCANY-2305
and am stuck at specifying wsdl.endpoint in wsdlElement (lines 46 to 49 in
Web Service Binding Specification v1.00). I am wondering if there is
anything wrong with the wsdl I am using or if Tuscany does not support
WSDL2.0. Please help. The following is a WSDL2.0 document I am using:
?xml version=1.0 encoding=UTF-8?
wsdl:description
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:ns0=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:wsdl=http://www.w3.org/ns/wsdl;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:wsoap=http://www.w3.org/ns/wsdl/soap;
xsi:schemaLocation=http://www.w3.org/ns/wsdl
http://www.w3.org/2007/06/wsdl/wsdl20.xsd;
wsdl:types
xs:schema attributeFormDefault=qualified
elementFormDefault=qualified targetNamespace=
http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:ns=
http://wsbinding.vtest.sca.tuscany.apache.org;
xs:element name=getGreetings
xs:complexType
xs:sequence
xs:element minOccurs=0 name=param0
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getGreetingsResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=getGreetingsRequest
wsdl:part name=parameters element=ns0:getGreetings/
/wsdl:message
wsdl:message name=getGreetingsResponse
wsdl:part name=parameters element=ns0:getGreetingsResponse/
/wsdl:message
wsdl:interface name=AServiceInterface
wsdl:operation name=getGreetings
pattern=http://www.w3.org/ns/wsdl/in-out;
wsdl:input element=ns0:getGreetingsRequest/
wsdl:output element=ns0:getGreetingsResponse/
/wsdl:operation
/wsdl:interface
wsdl:binding name=AServiceSoapBinding interface=ns0:AServiceInterface
type=http://www.w3.org/ns/wsdl/soap;
wsoap:version=1.1
wsoap:protocol=http://www.w3.org/2006/01/soap11/bindings/HTTP/;
wsdl:operation ref=ns0:getGreetings
wsoap:action=
http://wsbinding.vtest.sca.tuscany.apache.org/getGreetings/
/wsdl:binding
wsdl:service name=AService interface=ns0:AServiceInterface
wsdl:documentationMy first service/wsdl:documentation
wsdl:endpoint name=AServiceEndPoint binding=ns0:AServiceSoapBinding
address=http://localhost:9000/AService/
/wsdl:service
/wsdl:description
The following is my composite file:
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://vtest;
name=port-binding
component name=AComponent
implementation.java
class=org.apache.tuscany.sca.vtest.wsbinding.impl.AServiceImpl/
service name=AService
binding.ws wsdlElement=
http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.endpoint(AService/AServiceEndPoint)
/
/service
/component
component name=AClientComponent
implementation.java
class=org.apache.tuscany.sca.vtest.wsbinding.impl.AClientServiceImpl/
reference name=aService
binding.ws uri=http://localhost:9000/AService/
/reference
/component
/composite
The following is the exception I am getting:
org.osoa.sca.ServiceRuntimeException: java.lang.RuntimeException:
org.apache.tuscany.sca.contribution.service.ContributionReadException:
javax.wsdl.WSDLException: WSDLException (at /wsdl:description):
faultCode=INVALID_WSDL: Expected element '{
http://schemas.xmlsoap.org/wsdl/}definitions'.
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.vtest.wsbinding.EndpointTestCase.startServer(EndpointTestCase.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at
org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at
[jira] Updated: (TUSCANY-2305) vtests for service binding.ws
[
https://issues.apache.org/jira/browse/TUSCANY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2305:
-
Attachment: TUSCANY-2305.patch
TUSCANY-2305.patch: Added vtest for wsdl.service, wsdl.port, wsdl.endpoint and
wsdl.binding types specified in wsdlElement on service binding.ws. Marked the
tests for wsdl.service (see TUSCANY-2298) and wsdl.endpoint (as I am hitting an
error with a WSDL2.0 document) with @Ignore.
vtests for service binding.ws
-
Key: TUSCANY-2305
URL: https://issues.apache.org/jira/browse/TUSCANY-2305
Project: Tuscany
Issue Type: Bug
Components: Java SCA Verification Tests
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Attachments: TUSCANY-2305.patch
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of
a WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the
intended WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to
an existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this
element is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
69
70 2.1.1 Endpoint URI resolution
71 The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a
relative URI, in which
80 case it is relative to the URI defined in (2) or (3). The wsa:Address
element can be the empty
81 relative URI, in which case it uses the URI defined in (2) or (3)
directly. This allows the EPR
82 writer to specify reference parameters, metadata and other EPR contents
while allowing the URI
83 to be chosen by the deployer.
84 To reference a WSDL document and also specify an EPR, the wsdlElement
attribute must refer to
85 a binding element in the WSDL and not an endpoint or service.
-
--
This message
[jira] Updated: (TUSCANY-2305) vtests for service binding.ws
[
https://issues.apache.org/jira/browse/TUSCANY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2305:
-
Attachment: (was: TUSCANY-2305-2.patch)
vtests for service binding.ws
-
Key: TUSCANY-2305
URL: https://issues.apache.org/jira/browse/TUSCANY-2305
Project: Tuscany
Issue Type: Bug
Components: Java SCA Verification Tests
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Attachments: TUSCANY-2305.patch
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of
a WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the
intended WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to
an existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this
element is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
69
70 2.1.1 Endpoint URI resolution
71 The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a
relative URI, in which
80 case it is relative to the URI defined in (2) or (3). The wsa:Address
element can be the empty
81 relative URI, in which case it uses the URI defined in (2) or (3)
directly. This allows the EPR
82 writer to specify reference parameters, metadata and other EPR contents
while allowing the URI
83 to be chosen by the deployer.
84 To reference a WSDL document and also specify an EPR, the wsdlElement
attribute must refer to
85 a binding element in the WSDL and not an endpoint or service.
-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2305) vtests for service binding.ws
[
https://issues.apache.org/jira/browse/TUSCANY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2305:
-
Attachment: TUSCANY-2305-2.patch
TUSCANY-2305-2.patch: Added test for EndpointReference element. Please apply
both the patches.
vtests for service binding.ws
-
Key: TUSCANY-2305
URL: https://issues.apache.org/jira/browse/TUSCANY-2305
Project: Tuscany
Issue Type: Bug
Components: Java SCA Verification Tests
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Attachments: TUSCANY-2305.patch
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of
a WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the
intended WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to
an existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this
element is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
69
70 2.1.1 Endpoint URI resolution
71 The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a
relative URI, in which
80 case it is relative to the URI defined in (2) or (3). The wsa:Address
element can be the empty
81 relative URI, in which case it uses the URI defined in (2) or (3)
directly. This allows the EPR
82 writer to specify reference parameters, metadata and other EPR contents
while allowing the URI
83 to be chosen by the deployer.
84 To reference a WSDL document and also specify an EPR, the wsdlElement
attribute must refer to
85 a binding element in the WSDL and not an endpoint or service.
-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2305) vtests for service binding.ws
[
https://issues.apache.org/jira/browse/TUSCANY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2305:
-
Attachment: TUSCANY-2305-2.patch
vtests for service binding.ws
-
Key: TUSCANY-2305
URL: https://issues.apache.org/jira/browse/TUSCANY-2305
Project: Tuscany
Issue Type: Bug
Components: Java SCA Verification Tests
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Attachments: TUSCANY-2305-2.patch, TUSCANY-2305.patch
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of
a WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the
intended WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to
an existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this
element is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
69
70 2.1.1 Endpoint URI resolution
71 The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a
relative URI, in which
80 case it is relative to the URI defined in (2) or (3). The wsa:Address
element can be the empty
81 relative URI, in which case it uses the URI defined in (2) or (3)
directly. This allows the EPR
82 writer to specify reference parameters, metadata and other EPR contents
while allowing the URI
83 to be chosen by the deployer.
84 To reference a WSDL document and also specify an EPR, the wsdlElement
attribute must refer to
85 a binding element in the WSDL and not an endpoint or service.
-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2305) vtests for service binding.ws
[
https://issues.apache.org/jira/browse/TUSCANY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2305:
-
Patch Info: [Patch Available]
Assignee: (was: Vamsavardhana Reddy)
Marking patch available and unassigning.
vtests for service binding.ws
-
Key: TUSCANY-2305
URL: https://issues.apache.org/jira/browse/TUSCANY-2305
Project: Tuscany
Issue Type: Bug
Components: Java SCA Verification Tests
Reporter: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Attachments: TUSCANY-2305-2.patch, TUSCANY-2305.patch
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of
a WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the
intended WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to
an existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this
element is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
69
70 2.1.1 Endpoint URI resolution
71 The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a
relative URI, in which
80 case it is relative to the URI defined in (2) or (3). The wsa:Address
element can be the empty
81 relative URI, in which case it uses the URI defined in (2) or (3)
directly. This allows the EPR
82 writer to specify reference parameters, metadata and other EPR contents
while allowing the URI
83 to be chosen by the deployer.
84 To reference a WSDL document and also specify an EPR, the wsdlElement
attribute must refer to
85 a binding element in the WSDL and not an endpoint or service.
-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2309) vtest for Endpoint URI resolution in binding.ws
vtest for Endpoint URI resolution in binding.ws - Key: TUSCANY-2309 URL: https://issues.apache.org/jira/browse/TUSCANY-2309 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Web Service Binding Specification v1.00 - Section 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. 84 To reference a WSDL document and also specify an EPR, the wsdlElement attribute must refer to 85 a binding element in the WSDL and not an endpoint or service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2305) vtests for service binding.ws
[
https://issues.apache.org/jira/browse/TUSCANY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vamsavardhana Reddy updated TUSCANY-2305:
-
Description:
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 - lines 26 to 68:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of a
WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the intended
WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to an
existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this element
is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
-
was:
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of a
WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the intended
WSDL document
58 is to be found
[jira] Created: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in WSDL endpoint or EndpointReference
Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in WSDL endpoint or EndpointReference -- Key: TUSCANY-2310 URL: https://issues.apache.org/jira/browse/TUSCANY-2310 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. -- I am using a URI http://localhost:8080/AService; on binding.ws element. With this in place, Issue 1: When I use an empty wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService; whereas it is resolved to http://localhost:8080/;. Issue 2: When I use a relative uri of inAddress in wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService/inAddress; whereas it is resolved to http://localhost:8080/inAddress;. The bottom line is that the Endpoint URI resolution is not correct when relative URI's are used in WSDL endpoint or in the wsa:Address of an EPR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference
[ https://issues.apache.org/jira/browse/TUSCANY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2310: - Description: Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. -- I am using a URI http://localhost:8080/AService; on binding.ws element. With this in place, Issue 1: When I use an empty wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService; whereas it is resolved to http://localhost:8080/;. Issue 2: When I use a relative uri of inAddress in wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService/inAddress; whereas it is resolved to http://localhost:8080/inAddress;. The bottom line is that the Endpoint URI resolution is not correct when relative URI's is used in wsa:Address of an EPR. was: Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. -- I am using a URI http://localhost:8080/AService; on binding.ws element. With this in place, Issue 1: When I use an empty wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService; whereas it is resolved to http://localhost:8080/;. Issue 2: When I use a relative uri of inAddress in wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService/inAddress; whereas it is resolved to http://localhost:8080/inAddress;. The bottom line is that the Endpoint URI resolution is not correct when relative URI's are used in WSDL endpoint or in the wsa:Address of an EPR. Summary: Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference (was: Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in WSDL endpoint or EndpointReference) Endpoint URI resolution in the case when a relative URI specified in the WSDL endpoint seems to work fine. Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference Key: TUSCANY-2310 URL: https://issues.apache.org/jira/browse/TUSCANY-2310 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined
[jira] Updated: (TUSCANY-2309) vtest for Endpoint URI resolution in binding.ws
[ https://issues.apache.org/jira/browse/TUSCANY-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2309: - Attachment: TUSCANY-2309.patch TUSCANY-2309.patch: Added vtests for URI precedence. Marked the tests corresponding to relative URI in wsa:Address element of EPR with @Ignore. See TUSCANY-2310. vtest for Endpoint URI resolution in binding.ws - Key: TUSCANY-2309 URL: https://issues.apache.org/jira/browse/TUSCANY-2309 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2309.patch Web Service Binding Specification v1.00 - Section 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. 84 To reference a WSDL document and also specify an EPR, the wsdlElement attribute must refer to 85 a binding element in the WSDL and not an endpoint or service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2309) vtest for Endpoint URI resolution in binding.ws
[ https://issues.apache.org/jira/browse/TUSCANY-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2309: - Assignee: (was: Vamsavardhana Reddy) Unassigning so that a committer can pickup. vtest for Endpoint URI resolution in binding.ws - Key: TUSCANY-2309 URL: https://issues.apache.org/jira/browse/TUSCANY-2309 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2309.patch Web Service Binding Specification v1.00 - Section 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. 84 To reference a WSDL document and also specify an EPR, the wsdlElement attribute must refer to 85 a binding element in the WSDL and not an endpoint or service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2309) vtest for Endpoint URI resolution in binding.ws
[ https://issues.apache.org/jira/browse/TUSCANY-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2309: - Patch Info: [Patch Available] vtest for Endpoint URI resolution in binding.ws - Key: TUSCANY-2309 URL: https://issues.apache.org/jira/browse/TUSCANY-2309 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2309.patch Web Service Binding Specification v1.00 - Section 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. 84 To reference a WSDL document and also specify an EPR, the wsdlElement attribute must refer to 85 a binding element in the WSDL and not an endpoint or service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference
[ https://issues.apache.org/jira/browse/TUSCANY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned TUSCANY-2310: Assignee: Vamsavardhana Reddy Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference Key: TUSCANY-2310 URL: https://issues.apache.org/jira/browse/TUSCANY-2310 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. -- I am using a URI http://localhost:8080/AService; on binding.ws element. With this in place, Issue 1: When I use an empty wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService; whereas it is resolved to http://localhost:8080/;. Issue 2: When I use a relative uri of inAddress in wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService/inAddress; whereas it is resolved to http://localhost:8080/inAddress;. The bottom line is that the Endpoint URI resolution is not correct when relative URI's is used in wsa:Address of an EPR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference
[ https://issues.apache.org/jira/browse/TUSCANY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2310: - Attachment: TUSCANY-2310.patch TUSCANY-2310.patch: Fixes the problem in Axis2ServiceProvider.computeActualURI(). Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference Key: TUSCANY-2310 URL: https://issues.apache.org/jira/browse/TUSCANY-2310 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2310.patch Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. -- I am using a URI http://localhost:8080/AService; on binding.ws element. With this in place, Issue 1: When I use an empty wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService; whereas it is resolved to http://localhost:8080/;. Issue 2: When I use a relative uri of inAddress in wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService/inAddress; whereas it is resolved to http://localhost:8080/inAddress;. The bottom line is that the Endpoint URI resolution is not correct when relative URI's is used in wsa:Address of an EPR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference
[ https://issues.apache.org/jira/browse/TUSCANY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2310: - Patch Info: [Patch Available] Assignee: (was: Vamsavardhana Reddy) Unassigning so that a committer can pickup. Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference Key: TUSCANY-2310 URL: https://issues.apache.org/jira/browse/TUSCANY-2310 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2310.patch Web Service Binding Specification v1.00 - Sec 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. -- I am using a URI http://localhost:8080/AService; on binding.ws element. With this in place, Issue 1: When I use an empty wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService; whereas it is resolved to http://localhost:8080/;. Issue 2: When I use a relative uri of inAddress in wsa:Address element, the Endpoint URI resolved should be http://localhost:8080/AService/inAddress; whereas it is resolved to http://localhost:8080/inAddress;. The bottom line is that the Endpoint URI resolution is not correct when relative URI's is used in wsa:Address of an EPR. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2309) vtest for Endpoint URI resolution in binding.ws
[ https://issues.apache.org/jira/browse/TUSCANY-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2309: - Attachment: TUSCANY-2309-new.patch TUSCANY-2309-new.patch: Please use this patch as TUSCANY-2310 is now fixed (patch is waiting in the JIRA). vtest for Endpoint URI resolution in binding.ws - Key: TUSCANY-2309 URL: https://issues.apache.org/jira/browse/TUSCANY-2309 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2309-new.patch, TUSCANY-2309.patch Web Service Binding Specification v1.00 - Section 2.1.1 - Lines 70 to 85: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification 79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a relative URI, in which 80 case it is relative to the URI defined in (2) or (3). The wsa:Address element can be the empty 81 relative URI, in which case it uses the URI defined in (2) or (3) directly. This allows the EPR 82 writer to specify reference parameters, metadata and other EPR contents while allowing the URI 83 to be chosen by the deployer. 84 To reference a WSDL document and also specify an EPR, the wsdlElement attribute must refer to 85 a binding element in the WSDL and not an endpoint or service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2282) Poor warning issued when annotating private field with @Callback
[ https://issues.apache.org/jira/browse/TUSCANY-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned TUSCANY-2282: Assignee: Vamsavardhana Reddy Poor warning issued when annotating private field with @Callback Key: TUSCANY-2282 URL: https://issues.apache.org/jira/browse/TUSCANY-2282 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor I inadvertently marked a private field with @Callback and received the following warning: WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class java.lang.Void) is found on private org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback I should have realized sooner what the real problem was (private fields cannot be annotated) but a message like: WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class java.lang.Void) is found on private org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback. You must not annotate private fields and if you do then the runtime will ignore them and only give you this warning. I think an exception would be even better since the application will not work without the requested injection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2282) Poor warning issued when annotating private field with @Callback
[ https://issues.apache.org/jira/browse/TUSCANY-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2282: - Attachment: TUSCANY-2282.patch TUSCANY-2282.patch: Throws an exception when an @Callback annotation is present on a private method or private field. Poor warning issued when annotating private field with @Callback Key: TUSCANY-2282 URL: https://issues.apache.org/jira/browse/TUSCANY-2282 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Vamsavardhana Reddy Priority: Minor Attachments: TUSCANY-2282.patch I inadvertently marked a private field with @Callback and received the following warning: WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class java.lang.Void) is found on private org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback I should have realized sooner what the real problem was (private fields cannot be annotated) but a message like: WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class java.lang.Void) is found on private org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback. You must not annotate private fields and if you do then the runtime will ignore them and only give you this warning. I think an exception would be even better since the application will not work without the requested injection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2282) Poor warning issued when annotating private field with @Callback
[ https://issues.apache.org/jira/browse/TUSCANY-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2282: - Patch Info: [Patch Available] Fix Version/s: Java-SCA-Next Assignee: (was: Vamsavardhana Reddy) Unassigning so that a committer can pickup. Poor warning issued when annotating private field with @Callback Key: TUSCANY-2282 URL: https://issues.apache.org/jira/browse/TUSCANY-2282 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Priority: Minor Fix For: Java-SCA-Next Attachments: TUSCANY-2282.patch I inadvertently marked a private field with @Callback and received the following warning: WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class java.lang.Void) is found on private org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback I should have realized sooner what the real problem was (private fields cannot be annotated) but a message like: WARNING: Invalid annotation @org.osoa.sca.annotations.Callback(value=class java.lang.Void) is found on private org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.AServiceCallback org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.impl.BServiceImpl.callback. You must not annotate private fields and if you do then the runtime will ignore them and only give you this warning. I think an exception would be even better since the application will not work without the requested injection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2305) vtests for service binding.ws
vtests for service binding.ws
-
Key: TUSCANY-2305
URL: https://issues.apache.org/jira/browse/TUSCANY-2305
Project: Tuscany
Issue Type: Bug
Components: Java SCA Verification Tests
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Create vtests for service webservice binding as per Web Service Binding
Specification Spec v1.00 - Sec 2.1 and 2.1.1 - lines 26 to 85:
-
26 2.1 Web Service Binding Schema
27 The Web Service binding element is defined by the following pseudo-schema.
28 binding.ws wsdlElement=xs:anyURI?
29 wsdli:wsdlLocation=list of xs:anyURI?
30 ...
31 wsa:EndpointReference.../wsa:EndpointReference*
32 ...
33 /binding.ws
34
35 • /binding.ws/@wsdlElement - optional attribute that specifies the URI of a
WSDL element.
36 The use of this attribute indicates that the SCA binding points to the
specified element in an
37 existing WSDL document. The URI can have the following forms:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
42 o Port (WSDL 1.1):
43 WSDL-namespace-URI#wsdl.port(service-name/port-name)
44 In this case, the identified port in the WSDL 1.1 Service must have an
equivalent
45 PortType with the SCA service or reference.
46 o Endpoint (WSDL 2.0):
47 WSDL-namespace-URI#wsdl.endpoint(service-name/endpoint-name)
48 In this case, the identified endpoint in the WSDL 2.0 Service must have an
equivalent
49 PortType with the SCA service or reference.
50 o Binding:
51 WSDL-namespace-URI#wsdl.binding(binding-name)
52 In this case, the identified WSDL binding must have an equivalent PortType
with the SCA
53 service or reference. In this case the endpoint address URI for the SCA
service or
54 reference must be provided via the URI attribute on the binding.
55 • /binding.ws/@wsdli:wsdlLocation - optional attribute that specifies the
location of the
56 WSDL document. This attribute can be specified in the event that the
WSDL-namespace-
57 URI in the 'endpoint' attribute is not dereferencable, or when the intended
WSDL document
58 is to be found at a different location than the one pointed to by the
WSDL-namespace-
59 URI. The use of this attribute indicates that the WSDL binding points to an
existing WSDL
60 document.
61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6]
EndpointReference
62 that specifies the endpoint for the service or reference. When this element
is present along
63 with the wsdlElement attribute on the parent element, the wsdlElement
attribute value MUST
64 be of the 'Binding' form as specified above, i.e. WSDL-namespace-
65 URI#wsdl.binding(binding-name).
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow
extensibility via
67 attributes.
SCA Service Component Architecture
WS Binding Specification V1.00 March 2 3 007
68 • /binding.ws/any - this is an extensibility mechanism to allow
extensibility via elements.
69
70 2.1.1 Endpoint URI resolution
71 The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
79 The URI in the WSDL endpoint or in the wsa:Address of an EPR may be a
relative URI, in which
80 case it is relative to the URI defined in (2) or (3). The wsa:Address
element can be the empty
81 relative URI, in which case it uses the URI defined in (2) or (3) directly.
This allows the EPR
82 writer to specify reference parameters, metadata and other EPR contents
while allowing the URI
83 to be chosen by the deployer.
84 To reference a WSDL document and also specify an EPR, the wsdlElement
attribute must refer to
85 a binding element in the WSDL and not an endpoint or service.
-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
