Raymond,
The comment "junit.framework.AssertionFailedError: expected:<http://abcuri>
but was:<http://abcuri>" I had in @Ignore in the testcase code may have lead
to some confusion. I agree that uri1.equals(uri2) is not same as
uri1.toString().equals(uri2.toString()). The issue I am trying to bring up,
which I guess I am unsuccessful so far, is that if I have a service method
that takes a URI and returns the same URI back, and if I invoke that
"remotable" service with uri1 as parameter, the value that is returned (say
uri3) equals uri1 (i.e. uri1.equals(uri3) is true). If I have another
service method that takes a URI[] and returns back the same URI[] and I
invoke this method with an URI array that contains just one element uri1,
then the URI that is returned is not equal to uri1.
uri1 is creating problems when it passed to the service method as an array
element. So, it has to be a data transformation problem.
++Vamsi
On Tue, Jun 10, 2008 at 9:23 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here is a simple test case to prove my point:
>
> public class URITestCase {
> @Test
> public void testURI() {
> URI uri = URI.create("http://abc";);
> URI uri1 = uri.resolve("uri");
> URI uri2 = URI.create("http://abcxyz";);
> Assert.assertEquals(uri1, uri2);
> }
> }
>
> The Assert will fail, even though the uri1.toString() equals to
> uri2.toString().
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 10, 2008 8:26 AM
> To: <tuscany-dev@ws.apache.org>
> Subject: Re: Databinding tests for array of java.net.URI
>
>
> Hi Raymond,
>>
>> Whether or not resolve() works with http://abc, I have a URI created as
>> URI.create("http://abc";).resolve("xyz") and java does not complain about
>> this URI object . The current problem can be restated that this URI
>> object
>> can not be passed in an array of URI objects back and forth between client
>> and service component in case of a remotable service. The URI object can
>> be
>> passed between the client and service components properly when the service
>> method takes an URI as argument.
>>
>> ++Vamsi
>>
>> On Tue, Jun 10, 2008 at 8:33 PM, Raymond Feng <[EMAIL PROTECTED]>
>> wrote:
>>
>> I think it's a problem in the test case. The resolve() cannot work with
>>> http://abc (which abc is treated as a host name). I changed it to
>>> http://abc/, then it works well.
>>>
>>> You can simply create a test case using URIs only without Tuscany in the
>>> picture.
>>>
>>> Thanks,
>>> Raymond
>>> --------------------------------------------------
>>> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
>>> Sent: Tuesday, June 10, 2008 2:20 AM
>>> To: <tuscany-dev@ws.apache.org>
>>> Subject: Databinding tests for array of java.net.URI
>>>
>>>
>>> I am using the following URI's in my test:
>>>
>>>> URI[] uris = new URI[3];
>>>> uris[0] = URI.create("a/b/c");
>>>> uris[1] = URI.create("http://abc";);
>>>> uris[2] = URI.create("ftp://a/b";);
>>>>
>>>> The return value from the service method is inputUri.resolve("uri").
>>>>
>>>> One service method takes an uri as input and returns the changed uri as
>>>> given above. Another method takes an array of uri as input and returns
>>>> an
>>>> array of uri where each element in the returned array contains an uri
>>>> which
>>>> is changed as given above. The remotable service invoked over
>>>> binding.sca
>>>> is able to provide expected return value for uris[1] with the method
>>>> that
>>>> takes URI as argument. But, with the method that takes URI array as
>>>> argument, the return value for uris[1] is not as expected.
>>>>
>>>> In the failing case the input uri has (authority = "abc", host = "abc",
>>>> path
>>>> = "") , expected uri has (authority = "abc", host = "abc", path = "uri")
>>>> and
>>>> the uri returned from the service method has (authority="abcuri", host =
>>>> "abcuri", path = ""). I have verified through the debugger that the
>>>> array
>>>> being returned by the service method has the second element as expected.
>>>> But, once the array is returned to the caller after data
>>>> transformations,
>>>> the element is changed. There definitely is a problem with the data
>>>> transformation.
>>>>
>>>>
>>>>
>>
