Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Vasil Vasilev" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 27, 2007 1:17 PM
Subject: Re: Current XQuery implementation issues
Hi all,
First some update of the Saxon related issues: You can see TUSCANY-1536
for information what I have changed. Could someone apply the changes in
the repository?
I'll apply the patch. Thank you for the contribution.
When I applied the changes I found the following problems:
1. When serializing DataObject to stream using the following code:
XMLHelper.save(DataObject, null, rootElementName, OutputStream);
No prefices are attached to the serialized xml elements. This is something
that is introduced recently, because previously the behavior is was
different - each element was prefixed with the right prefix.
Did you try to use a non-null namespace?
2. If you open the xqueryquotewsclient.composite file you will see that I
set xml properties to the QuoteJoinPropertiesComponent. If you note you
will see that I have described each element and each attribute of the xml
with a prefix. For example:
<pri:priceQuote xmlns:pri="http://www.example.org/price";>
<pri:customerName>Acme Inc</pri:customerName>
<pri:shipAddress pri:street="12 Springs Rd"
pri:city="Morris Plains" pri:state="nj" pri:zip="07960" />
....
This style corresponds to the XSD attributeFormDefault="qualified".
However if I omit the prefices of the attributes:
<pri:priceQuote xmlns:pri="http://www.example.org/price";>
<pri:customerName>Acme Inc</pri:customerName>
<pri:shipAddress street="12 Springs Rd" city="Morris
Plains" state="nj" zip="07960" />
This style corresponds to the XSD attributeFormDefault="unqualified" which
is the default.
An exception is thrown during initialiation of the SCA domain:
org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
at
xquery.quote.XQueryQuoteClientTestCase.startClient(XQueryQuoteClientTestCase.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at
org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at
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: java.lang.NullPointerException
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.declareNamespace(BaseArtifactProcessor.java:681)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.loadElement(BaseArtifactProcessor.java:732)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.readPropertyValue(BaseArtifactProcessor.java:633)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.readAbstractProperty(BaseArtifactProcessor.java:332)
at
org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.readProperty(BaseArtifactProcessor.java:348)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:231)
at
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:68)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:73)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:63)
at
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:43)
at
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:73)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:369)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:313)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:160)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.<init>(DefaultSCADomain.java:117)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 22 more
Do you think that both issues are bugs? Should I report a Jira for them?
This is a bug. The code doesn't handle the case that the target namespace is
null.
Now about the other stuff :)
About 2: Let me explain my impression first, why I thought I have done a
hack: When the SCA Domain is started, upon java interface introspection,
the databindings of the Interface -> Operation -> DataType-s are set. And
this is done only if the interface is declared to be remotable. Otherwise
the databinding remains null.
However, when the runtime components are initialized - in the XQuery
implementation provider I set databindings for the same Interface ->
Operation -> DataType-s to Saxon.
I don't know why, but this tricks the framework, when creating the wires
to include data transformer in the invocation chain. I haven't elaborated
why this happens, because it worked. But I think that it is better for my
implementation provider in some way to explicitely state that he wants to
set only the data binding of the target operation, not generally the
databinding of the Interface -> Operation -> DataType-s
We had some discussions in this area before. There are a few factors:
1) A model object represents the XML definition for <interface.xxx>
elements, say XXXInterface.
2) The interface type which is introspected from the java interface or WSDL
portType. The same type can be referenced by multiple <interface.xxx>
elements and therefore it can be shared by multiple XXXInterface instances.
3) A way to indicate the databinding for an instance of XXXInterface. If not
specified, the databinding is default to the one in the interface type.
At this moment, we don't have a clean separation of 1 & 2. We should fix it
before the 1.0 release.
About 4: Sorry i is my mistake. I ment the net.sf.saxon.Configuration
object. I want to preserve it the first time it is created for a given
invokation. For example this could happen when for first time DataObejct
is transformed to NodeInfo. The I want all further transformation and the
invokation in the XQueryInvoker to use the same configuration object. I
want that this configuration object is invalidated after the invocation
finishes. Currently I am doing not very good workaronds to prevent this:
see comments in SaxonDataBindingHelper and XQueryInvoker for details.
About 7: This is an assumption I make in the
DataObject2NodeInfoTransformer in order to serialize the DataObject to an
output stream, which is then used to prepare the NodeInfo Saxon object
FYI, the tuscany databinding framework can support multi-hop transformation
by leveraging transformers in the graph.For example, if we have two
transformers in Tuscany:
Transformer 1: SDO --> XMLStreamReader
Transformer 2: XMLStreamReader --> Saxon NodeInfo
Then we can convert SDO into NodeInfo without writing a direct transformer
from SDO to Saxon NodeInfo.
I'll look into the databinding-saxon more and comment later.
About 8: OK. I will retest and create a Jira if necessary.
About scope: This was just a thought. But if we consider the scenarios
where this implementation will be used (data integration and mediation) I
do not see any use.
Bye, Vasil
>-------- Оригинално писмо --------
>От: Jean-Sebastien Delfino <[EMAIL PROTECTED]>
>Относно: Re: Current XQuery implementation issues
>До: [email protected]
>Изпратено на: Вторник, 2007, Август 21 22:44:32 EEST
>----------------------------------
>
>Hi Vasil,
>
>Some comments, answers, and more questions :) inline.
>
>Vasil Vasilev wrote:
>> Hi All,
>>
>> You can take a look at
>> http://issues.apache.org/jira/browse/TUSCANY-1536
>> for a list of current issues with the XQuery implementation.
>>
>> For issues 1 and 6 a wrote an e-mail to the Saxon mailing list and I am
>> waiting for an answer.
>>
>> For the other issues:
>> 2. I need the data type of the input and output of the data that go
>> into and out of the XQueryInvoker be of the Saxon data type. That's why
>> I need to set the data binding in some way from the side of the
>> XQueryInvoker. What I am not sure is if this is the right way, or is
>> this more a hack to do it?
>>
>
>What you're describing sounds right to me. The general idea is that an
>implementation should be able to tag the interface it's providing or
>requiring with a particular databinding (because the implementation
>logic wants that particular databinding, or because the technology
>you're using in your implementation extension works with that
>databinding, Saxon in your case).
>
>I'd be interested in your feedback and whether you think it's easy
>enough to do, or if it feels more like a hack :)
>
>You also mentioned in the JIRA that you had to make the interface
>remotable. There may be an issue with the Tuscany databinding framework
>here, I'd imagine that it you had a string of XQuery components (all
>using the same Saxon binding), you'd probably not want to have to mark
>their interfaces remotable.
>
>Raymond, what do you think? Isn't that an issue? why couldn't this work
>with a local interface as well?
>
>> 3. I didn't have the time to do it, but generally it is possible to be
>> done.
>>
>
>Yes I'd think so. It looks like a good thing to do as I guess most
>XQuery component developers will work with XSDs and will probably
>interact with Web Services as well.
>
>Some may even say that they only care about XML and don't want to have
>to deal with any Java code or Java interface :)
>
>> 4. I would like to know if a can use some kind of context, which is
>> associated with given request and if I can use this context to put some
>> data there. I do not want this context to be transferred in web service
>> invocation for example, but only in the chain of transformers to the
>> target invoker.
>>
>
>We may be able to extend the Tuscany Message or EndpointReference to
>carry extra context data, but could you give me a little more background
>on what kind of data you'd like to pass or keep around, and how it's
>going to be used?
>
>In the JIRA you mentioned "which configuration is associated with an
>invocation"... The message carrying an invocation should have pointers
>to assembly model representing the from (reference) and target
>(service), from which I think you could navigate to the binding model
>and its configuration. Is that the kind of configuration you're looking
>for? or some other configuration?
>
>> 5. This limitation is again due to the fact I didn't have time to
>> implement it.
>>
>
>Ok, time is always too short :)
>
>> 7, and 8 - are just questions if somebody knows is this the right way
>> to do it.
>>
>
>For 7, are you talking about Web Services? or is it an assumption you
>made in the XQuery component?
>
>(8) looks like bug, we should create a JIRA for it.
>
>> Another thing that we should think about is whether it is useful to
>> provide a scope for the XQuery implementation. Currently it is not
>> scoped.
>>
>>
>
>Ah interesting, I'm not an XQuery expert :) so do you have an example
>showing the kind of state that an XQuery component could support?
>
>Are you thinking about keeping variables around across multiple
>invocations of the same component?
>
>Thanks...
>
>> Bye, Vasil
>>
>> -----------------------------------------------------------------
>> Познай победителя във Формула 1 и спечели награда!
>> http://www.clubf1.net/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
>--
>Jean-Sebastien
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-----------------------------------------------------------------
ЕЛА и направи свой сайт, намери нови приятели!
http://www.zoom.bg/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
