Re: binding.ws in combination with doc/lit/unwrapped wsdl

[Vamsavardhana Reddy]

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.
> >
> > 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/";>
> >  
> > > elementFormDefault="qualified" targetNamespace="
> > http://wsbinding.vtest.sca.tuscany.apache.org"; xmlns:ns="
> > http://wsbinding.vtest.sca.tuscany.apache.org";>
> > > type="xs:string"/>
> > > nillable="true" type="xs:string"/>
> >
> >  
> >
> >  
> >
> >  
> >
> >  
> >
> >  
> >
> >  
> >
> >   > wsaw:Action="urn:getGreetings"/>
> >   > wsaw:Action="urn:getGreetingsResponse"/>
> >
> >  
> >
> >  
> >http://schemas.xmlsoap.org/soap/http"/>
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
> >  
> >
> >   type="ns0:AServicePortType">
> >http://schemas.xmlsoap.org/soap/http"/>
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
> >  
> >
> >  
> >
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
> >  
> >
> >  
> >http://schemas.xmlsoap.org/soap/http"/>
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
> >  
> >
> >  
> > > binding="ns0:AServicePortTypeBinding">
> >  http://localhost:8080/AService"/>
> >
> >  
> >
> >  
> >
> >  http://localhost:8080/AService/httpport"/>
> >
> > > binding="ns0:AServiceSOAP12Binding">
> >  http://localhost:8080/AService/soap12port
> > "/>
> >
> > > binding="ns0:AServiceSOAP11Binding">
> >  http://localhost:8080/AService/soap11port
> "/>
> >
> > > binding="ns0:AServiceSOAP12Binding">
> >  
> >
> > > binding="ns0:AServiceSOAP12Binding">
> >  
> >
> >  
> > 
> >
> > 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
> >  (

binding.ws in combination with doc/lit/unwrapped wsdl

[Vamsavardhana Reddy]

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.

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/";>
  
http://wsbinding.vtest.sca.tuscany.apache.org"; xmlns:ns="
http://wsbinding.vtest.sca.tuscany.apache.org";>



  

  

  

  

  

  

  
  

  

  
http://schemas.xmlsoap.org/soap/http"/>

  
  

  
  

  

  

  
http://schemas.xmlsoap.org/soap/http"/>

  
  

  
  

  

  

  


  
  

  
  

  

  

  
http://schemas.xmlsoap.org/soap/http"/>

  
  

  
  

  

  

  

  http://localhost:8080/AService"/>

  

  

  http://localhost:8080/AService/httpport"/>


  http://localhost:8080/AService/soap12port"/>


  http://localhost:8080/AService/soap11port"/>


  


  

  


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/";>
   
 http://wsbinding.vtest.sca.tuscany.apache.org"; xmlns:ns="
http://wsbinding.vtest.sca.tuscany.apache.org";>
-  
-
-  
-
-  
-
-  
-  
-
-  
-
-  
-
-  
+
+
 
   

I have tried a few combinations with interface.wsdl and wsdlElement with
binding.ws.  Here are the cases that work (here work means, the
clientcomponent is able to invoke the service successfully):

Case-1: interface.wsdl used both with service and reference.
http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://vtest"; name="mywsdltest">




http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.interface(AServicePortType)
"/>
http://localhost:8085/AService/endpointref"/>





http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.interface(AServicePortType)
"/>
http://localhost:8085/AService/endpointref"/>




Case-2: interface.java and wsdlElement on service binding.ws AND
interface.wsdl on reference.
http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://vtest"; name="mywsdltest">





http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.binding(AServiceSOAP11Binding)
"
uri="http://localhost:8085/AService/endpointref"/>





http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.interface(AServicePortType)
"/>
http://localhost:8085/AService/endpointref"/>





Case-3: wsdlElement on service binding.ws AND interface.wsdl on reference.
http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://vtest"; name="mywsdltest">




http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.binding(AServiceSOAP11Binding)
"
uri="http://localhost:8085/AService/endpointref"/>





http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.interface(AServicePortType)
"/>
http://localhost:8085/AService/endpointref"/>




Case-4: wsdlElement in binding.ws in both service and reference.
http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://vtest"; name="mywsdltest">




http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.binding(AServiceSOAP11Binding)
"
uri="http://localhost:8085/AService/endpointref"/>





http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.binding(AServiceSOAP11Binding)
"
uri="http://localhost:8085

[jira] Closed: (TUSCANY-2385) Problem with Databinding for URI and UUID objects when using binding.ws

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

[jira] Created: (TUSCANY-2389) null elements in Object array not getting passed over binding.ws

[Vamsavardhana Reddy (JIRA)]

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.

Re: Good practice for disabling/ignoring failing test cases

[Vamsavardhana Reddy]

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: 
> 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

[jira] Closed: (TUSCANY-2134) CallbackImpl has duplicate intent values when an intent is specified on service

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy closed TUSCANY-2134.



> CallbackImpl has duplicate intent values when an intent is specified on 
> service
> ---
>
> Key: TUSCANY-2134
> URL: https://issues.apache.org/jira/browse/TUSCANY-2134
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Assembly Model
>Affects Versions: Java-SCA-Next
>    Reporter: Vamsavardhana Reddy
>Assignee: Venkatakrishnan
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> I am using the following composite to deploy a conversational service.
> http://www.osoa.org/xmlns/sca/1.0";
> xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0";
> xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace="http://conversations";
> name="MyTest">
>  
> 
>  class="org.apache.tuscany.sca.mytest.MyConvServiceImpl"/>
> 
>  interface="org.apache.tuscany.sca.mytest.MyConvService"
> 
> callbackInterface="org.apache.tuscany.sca.mytest.MyConvCallback"/>
> 
> 
> 
> 
> 
> 
>  
>  
> I notice in the debugger that the service -> callback -> requiredIntents list 
> has duplicate values.

-- 
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

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Closed: (TUSCANY-2090) Test for uniqueness of ConversationIds

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2273) Return value of a method with @Init and @Destroy annotations must be a void

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2272) @Init and @Destroy annotations on a non-public method

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2349) TransformationException when invoking a method with byte array paramter using webservice binding

[Vamsavardhana Reddy (JIRA)]

 [ 
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.Test

[jira] Closed: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2340) Databinding integration tests

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2356) Databinding itests for Local service

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2373) RuntimeException: "no data binding for null" with binding.ws when the service interface uses generics

[Vamsavardhana Reddy (JIRA)]

 [ 
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:
>  Bean1 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.(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.(Axis2ReferenceBindingProvider.java:68)
> at 
> org.apache.tuscany.sca.b

[jira] Closed: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2378) Databinding tests for generics, parameterized and polymorphic types

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

Re: Good practice for disabling/ignoring failing test cases

[Vamsavardhana Reddy]

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
>

Databinding test for javax.xml.transform.Source problem

[Vamsavardhana Reddy]

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("A")).

The content I am from this source is as follows:

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:

http://jaxb.databindings.itest.sca.tuscany.apache.org/
">A

Notice the namespace and the change in the root tag.  Any suggestions on
changing the test?

[jira] Created: (TUSCANY-2387) Databinding problem for array of javax.xml.transform.Source with binding.sca and remotable service

[Vamsavardhana Reddy (JIRA)]

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)
at

[jira] Created: (TUSCANY-2386) Databinding problem for array of javax.xml.transform.Source with binding.ws

[Vamsavardhana Reddy (JIRA)]

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-2385) Problem with Databinding for URI and UUID objects when using binding.ws

[Vamsavardhana Reddy (JIRA)]

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] Closed: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Commented: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Re: Databinding tests for array of java.net.URI

[Vamsavardhana Reddy]

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: 
> 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: 
>>> 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() canno

Re: Databinding tests for array of java.net.URI

[Vamsavardhana Reddy]

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: 
> 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: 
>>> 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

[Vamsavardhana Reddy]

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: 
> 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.
>>
>>

[jira] Commented: (TUSCANY-2378) Databinding tests for generics, parameterized and polymorphic types

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[jira] Updated: (TUSCANY-2378) Databinding tests for generics, parameterized and polymorphic types

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Databinding tests for array of java.net.URI

[Vamsavardhana Reddy]

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.

[jira] Commented: (TUSCANY-2378) Databinding tests for generics and parameterized types

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

[jira] Created: (TUSCANY-2378) Databinding tests for generics and parameterized types

[Vamsavardhana Reddy (JIRA)]

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.

Re: [NOTICE] Scott Kurz voted as Tuscany committer

[Vamsavardhana Reddy]

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
>

Build error in sca\itest\properties

[Vamsavardhana Reddy]

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]

[jira] Updated: (TUSCANY-2373) RuntimeException: "no data binding for null" with binding.ws when the service interface uses generics

[Vamsavardhana Reddy (JIRA)]

 [ 
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:
>  Bean1 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.(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.(Axis2ReferenceBindingProvider.java:68)

Re: RuntimeException: "no data binding for null" with binding.ws when the service inteface uses generics

[Vamsavardhana Reddy]

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:
>> Bean1 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.(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.(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
>>
>>

RuntimeException: "no data binding for null" with binding.ws when the service inteface uses generics

[Vamsavardhana Reddy]

I have the following method in my service interface that uses binding.ws:
 Bean1 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.(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.(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

sca/tools/eclipse/plugins/core/.classpath file in svn

[Vamsavardhana Reddy]

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: Databinding integration tests

[Vamsavardhana Reddy]

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[] :

  

  

  
  

  

  

Whereas ?wsdl is generating the type:

  
  

  

  

++Vamsi



>
>
> Thanks,
> Raymond
>
> ------
> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 11:09 AM
> To: 
> 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
>>
>>

Re: Databinding integration tests

[Vamsavardhana Reddy]

Hi Raymond,

The credit goes to Simon Laws for the initial content and setting the pace.
I had a few additions and update to the test status.

Thanks for the update on byte[] support.  I will update the wiki once I
verify that the test passes.

Thanks and best regards,
Vamsi

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.
>
> Thanks,
> Raymond
>
> ------
> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 11:09 AM
> To: 
> 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
>>
>>

Databinding integration tests

[Vamsavardhana Reddy]

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

[jira] Updated: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

[jira] Updated: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Created: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

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] Created: (TUSCANY-2366) QName with just a localPart not getting passed in arrays with binding.ws to invoke service

[Vamsavardhana Reddy (JIRA)]

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.

Re: Strange problem with Calendar comparison

[Vamsavardhana Reddy]

Found the problem...  The Calendar object returned over binding.ws,
GregorianCalendar object, has a gregorianCutover field set to
-9223372036854775808 (== Long.MIN_VALUE).  Whereas the one returned by
Calendar.getInstance() has the field set to
GregorianCalendar.DEFAULT_GREGORIAN_CUTOVER = -1221929280L.  Here is
what javadoc for GregorianCalendar.setGregorianChange() says:  "To obtain a
pure Julian calendar, set the change date to Date(Long.MAX_VALUE).  To
obtain a pure Gregorian calendar,set the change date to
Date(Long.MIN_VALUE)."

++Vamsi

On Tue, Jun 3, 2008 at 3:37 PM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
wrote:

> 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:
>  but
> was:
>
> Any ideas what could be wrong?
>
> ++Vamsi
>
>

Strange problem with Calendar comparison

[Vamsavardhana Reddy]

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:
 but
was:

Any ideas what could be wrong?

++Vamsi

Re: [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[Vamsavardhana Reddy]

+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/
> 
>
> 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]
>

Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Vamsavardhana Reddy]

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
>

Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Vamsavardhana Reddy]

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
>

[jira] Updated: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests

[Vamsavardhana Reddy (JIRA)]

 [ 
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

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

[jira] Created: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests

[Vamsavardhana Reddy (JIRA)]

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] Created: (TUSCANY-2358) Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter

[Vamsavardhana Reddy (JIRA)]

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.



http://jaxb.databindings.itest.sca.tuscany.apache.org/";
xmlns:ns0="http://util.java/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>














...





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
  

  http://jaxws.java.interfacedef.sca.tuscany.apache.org/"; 
schemaLocation="MyServiceImplService_schema1.xsd"/>


  http://jaxb.dev.java.net/array"; 
schemaLocation="MyServiceImplService_schema2.xsd"/>

  

MyServiceImplService_schema2.xsd has
  

  

  

MyServiceImplService_schema1.xsd has
  

  

  
  

  

  

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.

Re: Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter

[Vamsavardhana Reddy]

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.
>>
>> 
>>
>>>elementFormDefault="qualified"
>>targetNamespace="
>> http://jaxb.databindings.itest.sca.tuscany.apache.org/";
>>xmlns:ns0="http://util.java/";
>>xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>>
>>
>>
>>>name="arg0" nillable="true" type="xs:string" />
>>
>>
>>
>>
>>
>>
>>>name="return" nillable="true" type="xs:string"
>> />
>>
>>
>>
>>...
>>
>>
>>
>> 
>>
>> 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
>>  
>>
>>  http://jaxws.java.interfacedef.sca.tuscany.apache.org/";
>> schemaLocation="MyServiceImplService_schema1.xsd"/>
>>
>>
>>  http://jaxb.dev.java.net/array";
>> schemaLocation="MyServiceImplService_schema2.xsd"/>
>>
>>  
>>
>> MyServiceImplService_schema2.xsd has
>>  
>>
>>  > maxOccurs="unbounded" nillable="true"/>
>>
>>  
>>
>> MyServiceImplService_schema1.xsd has
>>  
>>
>>  > minOccurs="0" maxOccurs="unbounded"/>
>>
>>  
>>  
>>
>>  > minOccurs="0" maxOccurs="unbounded"/>
>>
>>  
>>
>> 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] Updated: (TUSCANY-2356) Databinding itests for Local service

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

[jira] Created: (TUSCANY-2356) Databinding itests for Local service

[Vamsavardhana Reddy (JIRA)]

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.

Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter

[Vamsavardhana Reddy]

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.



http://jaxb.databindings.itest.sca.tuscany.apache.org/";
xmlns:ns0="http://util.java/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";>














...





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
  

  http://jaxws.java.interfacedef.sca.tuscany.apache.org/";
schemaLocation="MyServiceImplService_schema1.xsd"/>


  http://jaxb.dev.java.net/array";
schemaLocation="MyServiceImplService_schema2.xsd"/>

  

MyServiceImplService_schema2.xsd has
  

  

  

MyServiceImplService_schema1.xsd has
  

  

  
  

  

  

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

Re: Build failure in sca\modules\databinding-jaxb

[Vamsavardhana Reddy]

Has anyone else hit this build error?  The error is fixed after adding

javax.xml.ws
jaxws-api
2.1


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]
> 
>

Build failure in sca\modules\databinding-jaxb

[Vamsavardhana Reddy]

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]

TransformationException when using a two dimensional String array as parameter and return value of a service operation invoked with ws binding

[Vamsavardhana Reddy]

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 

[jira] Updated: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

[jira] Created: (TUSCANY-2351) byte array passed by reference when using sca binding even though implementation does not have @AllowsPassByReference

[Vamsavardhana Reddy (JIRA)]

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] Created: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types

[Vamsavardhana Reddy (JIRA)]

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-2349) TransformationException when invoking a method with byte array paramter using webservice binding

[Vamsavardhana Reddy (JIRA)]

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.ru

Re: TransformationException when using java interface definition with generics

[Vamsavardhana Reddy]

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 HelloService {
>>> }
>>>
>>> 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.(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.(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.assembl

Problem building sca\modules\interface-java-jaxws with jaxws-maven-plugin uncommented in pom.xml

[Vamsavardhana Reddy]

I have uncommented the jaxws-maven-plugin in
sca\modules\interface-java-jaxws\pom.xml.  The following is the xml
fragment:

org.codehaus.mojo
jaxws-maven-plugin
1.9


org.apache.tuscany.sca.interfacedef.java.jaxws.MyServiceImpl
true



process-test-classes

wsgen-test





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:


  ...
  VALUE
.

[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 org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginParameterException: Error
configuring: org.codehaus.mojo:jaxws-maven-plugin. Reason: Invalid or
missing parameters: [Moj

Re: TransformationException when using java interface definition with generics

[Vamsavardhana Reddy]

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 HelloService {
> }
>
> 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.(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.(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: 
> 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 HelloService {
>>   public E getGreetings(E name);
>> }
>> 
>> The following is the service implementat

TransformationException when using java interface definition with generics

[Vamsavardhana Reddy]

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 HelloService {
public E getGreetings(E name);
}

The following is the service implementation:
@Service(HelloService.class)
public class HelloServiceImpl implements HelloService {

public String getGreetings(String name) {
return "Hello "+name;
}
}

The following is the client interface that invokes the service:
public interface HelloServiceClient {
E getGreetingsForward(E name);
}

The following is the client implementation:
@Service(HelloServiceClient.class)
public class HelloServiceClientImpl implements HelloServiceClient {

private HelloService service;

@Reference
public void setHelloService(HelloService 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):
http://www.osoa.org/xmlns/sca/1.0";
   xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance";
   name="HelloService">






http://localhost:8080/hs-ep1"/>














http://localhost:8080/hs-ep1"/>





The following is the code I am using to invoke the service via client
components:
domain = SCADomain.newInstance("hello.composite");
String name = "Me  SCA";
HelloServiceClient helloServiceClient =
domain.getService(HelloServiceClient.class,
"HelloServiceClientSCAComponent");
String resp = helloServiceClient.getGreetingsForward(name);
System.out.println(resp);

name = "Me  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
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at o

Re: Graduation

[Vamsavardhana Reddy]

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-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces

[Vamsavardhana Reddy (JIRA)]

 [ 
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:
> 
> http://helloworld";
>   xmlns:tns="http://helloworld";
>   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>   name="helloworld">
> 
>  targetNamespace="http://helloworld"; xmlns="http://www.w3.org/2001/XMLSchema";>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  name="getGreetingsRequest"/>
>  name="getGreetingsResponse"/>
> 
> 
> 
> The following is the composite:
> 
> http://www.osoa.org/xmlns/sca/1.0";
>   targetNamespace="http://helloworld";
>   xmlns:hw="http://helloworld";
> name="helloworldws">
> 
> 
>   
>interface="http://helloworld#wsdl.interface(HelloWorld)" />
>   http://localhost:8085/HelloWorldService"/>
>   
> 
> 
> 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.Http11Protoc

[jira] Created: (TUSCANY-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces

[Vamsavardhana Reddy (JIRA)]

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:


http://helloworld";
  xmlns:tns="http://helloworld";
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
  xmlns:xsd="http://www.w3.org/2001/XMLSchema";
name="helloworld">


http://helloworld"; xmlns="http://www.w3.org/2001/XMLSchema";>




































The following is the composite:

http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://helloworld";
xmlns:hw="http://helloworld";
name="helloworldws">




http://helloworld#wsdl.interface(HelloWorld)" />
http://localhost:8085/HelloWorldService"/>




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)
at org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:63)
at 
org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(ThreadPoolWorkManager.java:221)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.wsdl.WSDLException: 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 com.ibm.wsdl.util.xml.DOMUtils.getPrefix(Unknown Source)
at com.ibm.wsdl.util.xml.DOMUtils.getQualifiedValue(Unknown Source)
at com.ibm.wsdl.extensions.soap.SOAPBindingSerializer.marshall(Unknown 
Source)
at com.ibm.w

Re: Conversational semantics using xml in SCDLs

[Vamsavardhana Reddy]

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:
> 
>
>> 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="myNonConversationalInterface" conversational="true">
>>
>> 
>>
>> 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
>>
> 
> 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.
>

Re: Conversational semantics using xml in SCDLs

[Vamsavardhana Reddy]

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:


 ...
  

  

  


  ...
  

  


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.oso

[jira] Updated: (TUSCANY-2311) Second equivalently typed callback field not injected

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

[jira] Updated: (TUSCANY-2311) Second equivalently typed callback field not injected

[Vamsavardhana Reddy (JIRA)]

 [ 
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 Map> instead of Map.

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-1867) @OneWay with String return type causes NullPointerException

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Reopened: (TUSCANY-1867) @OneWay with String return type causes NullPointerException

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Assigned: (TUSCANY-2311) Second equivalently typed callback field not injected

[Vamsavardhana Reddy (JIRA)]

 [ 
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.

Conversational semantics using xml in SCDLs

[Vamsavardhana Reddy]

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.

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".

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.

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.

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 element can
be used to specify the callback interface.  But this does not necessarily
tag the interface and its callback interface as the @Callback annotation
would.

6. conversational intent on a service or a reference element.
The conversational intent specified on a service or a reference element
seems to be inherited by the child callback element.  But, it is not
necessary that the callback interface of a conversational service is always
conversational.  Should the callback element "not inherit" the intents and
specify its own intents?

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




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
PS: I seem to attempt to eliminate the conversational intent altogether, but
that has nothing to do with the '007' in my mail id. :o)

[jira] Issue Comment Edited: (TUSCANY-2248) SOAP intents not being honored

[Vamsavardhana Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

 

can be replaced with 



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

 

can be replaced with 



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. 
>  binding="ns:HelloWorldServiceHttpBinding">
>location="http://localhost:8080/axis2/services/HelloWorldService"/>
>
>  
>   

-- 
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

[Vamsavardhana Reddy (JIRA)]

 [ 
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

 

can be replaced with 



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. 
>  binding="ns:HelloWorldServiceHttpBinding">
>location="http://localhost:8080/axis2/services/HelloWorldService"/>
>
>  
>   

-- 
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

[Vamsavardhana Reddy (JIRA)]

 [ 
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. 
>  binding="ns:HelloWorldServiceHttpBinding">
>location="http://localhost:8080/axis2/services/HelloWorldService"/>
>
>  
>   

-- 
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)

[Vamsavardhana Reddy]

+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 
>* ant elder 
>* Brady Johnson 
>* Frank Budinsky 
>* Ignacio Silva-Lepe 
>* Jean-Sebastien Delfino 
>* kelvin goodson 
>* Luciano Resende 
>* Mark Combellack 
>* Matthieu Riou 
>* Mike Edwards 
>* Paul Fremantle 
>* Pete Robbins 
>* Raymond Feng 
>* Simon Laws 
>* Simon Nash 
>* Venkata Krishnan 
>
> 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.
>

[jira] Updated: (TUSCANY-2309) vtest for "Endpoint URI resolution" in binding.ws

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Updated: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Assigned: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2309) vtest for "Endpoint URI resolution" in binding.ws

[Vamsavardhana Reddy (JIRA)]

 [ 
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] Updated: (TUSCANY-2309) vtest for "Endpoint URI resolution" in binding.ws

[Vamsavardhana Reddy (JIRA)]

 [ 
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

[Vamsavardhana Reddy (JIRA)]

 [ 
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-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in wsa:Address in EndpointReference

[Vamsavardhana Reddy (JIRA)]

 [ 
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 th

[jira] Created: (TUSCANY-2310) Incorrect Endpoint URI Resoultion in binding.ws when relative URIs are specified in WSDL endpoint or EndpointReference

[Vamsavardhana Reddy (JIRA)]

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-2305) vtests for service binding.ws

[Vamsavardhana Reddy (JIRA)]

 [ 
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 
31 ...*
32 ...
33 
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.service()
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.port(/)
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.endpoint(/)
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.binding()
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 
 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 
. 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.binding().
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 
31 ...*
32 ...
33 
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.service()
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.port(/)
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.endpoint(/)
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.binding()
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 
 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 
. 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.binding().
66 • /binding.ws/@{any} - this is an extensibility mechanism to allow 
extensibility via
67 attributes.
SCA S

[jira] Created: (TUSCANY-2309) vtest for "Endpoint URI resolution" in binding.ws

[Vamsavardhana Reddy (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
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

[Vamsavardhana Reddy (JIRA)]

 [ 
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  29 wsdli:wsdlLocation="list of xs:anyURI"?
> 30 ...>
> 31 ...*
> 32 ...
> 33 
> 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.service()
> 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.port(/)
> 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.endpoint(/)
> 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.binding()
> 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 
>  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 
>  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.  65 URI>#wsdl.binding().
> 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

[Vamsavardhana Reddy (JIRA)]

 [ 
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  29 wsdli:wsdlLocation="list of xs:anyURI"?
> 30 ...>
> 31 ...*
> 32 ...
> 33 
> 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.service()
> 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.port(/)
> 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.endpoint(/)
> 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.binding()
> 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 
>  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 
>  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.  65 URI>#wsdl.binding().
> 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

[Vamsavardhana Reddy (JIRA)]

 [ 
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  29 wsdli:wsdlLocation="list of xs:anyURI"?
> 30 ...>
> 31 ...*
> 32 ...
> 33 
> 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.service()
> 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.port(/)
> 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.endpoint(/)
> 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.binding()
> 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 
>  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 
>  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.  65 URI>#wsdl.binding().
> 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

[Vamsavardhana Reddy (JIRA)]

 [ 
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  29 wsdli:wsdlLocation="list of xs:anyURI"?
> 30 ...>
> 31 ...*
> 32 ...
> 33 
> 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.service()
> 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.port(/)
> 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.endpoint(/)
> 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.binding()
> 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 
>  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 
>  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.  65 URI>#wsdl.binding().
> 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.