Vasil Vasilev wrote:
Hi,
Some thoughts about the example simplification - really it would be good to simplify the sample, but the client+server scenario should remain as JUnit test I think.
+1 to keep the client/server scenario, I'd suggest to create an itest
module for it, something like itest/implementation-xquery.
You can see below some problems I currently have exactly with this scenario.
I started looking at the following issues:
1. sharing common Configuration object
2. Being able to directly implement a WSDL interface
Unfortunately I was not able to execute the sample JUnit test after I checked out the latest sources. The problem occurs when executing the scenario in which the XQuery component is a remote one and is exposed as Web Service.
When I investigated the problem it appeared that the "targetOperation" of the DataTransformationInteceptor on the server side (i.e. the one that is called by Axis2ServiceProvider.invokeTarget) has input type with SDO data bindings of the input parameters, while I should have had Saxon type data binding.
Not sure... Raymond, any idea? could this be caused by a recent change
to the DataBinding framework?
In the contrary if I look at the "contract" variable of the
Axis2ServiceProvider - the databinding of the input parameters of the operation are
correct.
Is there something done recently in this direction, which could have led to the
problem?
----------
One more note: Currently it will be possible (I will verify it after i have
finished with the implementation :) ) for an XQuery component to implement a
WSDL interface, bt it will not be possible to call a reference which has WSDL
interface. At least i do not see how, because Saxon wants a java interface,
which to be called. Can we think of some workaround?
How about asking on the saxon-help mailing list?
Bye, Vasil
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
