Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
Hi Ant,
I have posted a patch under JIRA Tuscany-418 for including e4x into the
javascript container. Please review and apply if found ok. Thanks.
Thanks
- Venkat
On 8/24/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Ant,
I have been able to do the injection of required JS XmlObjects into the
script. The service invocation works fine.
I am now looking at the references part and am bit stuck there. There is
a problem in converting the javascript xml objects to the Java counterparts
(something that is being done in the RhinoInvoker for services side).
How are references injected into the javascript? Right now I understand
that, using the reference name as mentioned in the componentType file I am
able to access this object. But how did it get inject in the first place?
Please help with some info or pointers. Thanks.
- Venkat
On 8/23/06, ant elder [EMAIL PROTECTED] wrote:
I've had some offline chats with Venkat about this. I'd not ported any
of
the E4X code over from M1 so Venkat is looking at that. The XML instance
utility being talked about is for JIRA TUSCANY-419. Here's a bit more
detail
on TUSCANY-419 and how it would work.
Today an E4X helloworld function looks like this:
function getGreeting(xmlIn) {
var greeting = e4xHello + xmlIn..*::in0;
var xmlOut =
helloworld:getGreetingsResponse xmlns:helloworld=
http://integration.rhino.container.tuscany.apache.org;
helloworld:getGreetingsReturn { greeting }
/helloworld:getGreetingsReturn
/helloworld:getGreetingsResponse;
return xmlOut;
}
There's a lot of boilerplate XML in there which could be determined
automatically from the WSDL, so ideally the function could rewritten
something like:
function getGreeting(xmlIn) {
var xmlOut = _getXML(getGreetingResponse);
xmlOut.getGreetingsReturn = e4xHello + xmlIn..*::in0;
return xmlOut;
}
The _getResponseXML function is a system supplied function that the
JavaScript container injects into the script environment. It returns an
E4X
XML object that is an representation of the WSDL schema with all the
values
defaulting. Thats worked out based on the interface of the component,
there
could be similar ones for references, eg, if there is a reference named
foo
you could do foo._getXML(fooType).
...ant
On 8/20/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Ant,
Is this something that works in M2 now? I remember doing a util for
creating xml instances for this.
When I see the current trunk's javascript container I don't see the
e4x
samples. Shall I try moving them over and intergrating with the xml
instance creation utility. Please let me know.
Thanks.
- Venkat
On 6/7/06, ant elder [EMAIL PROTECTED] wrote:
No reply to this yet...after a little playing around it seems to
work so
I'm
going to go ahead unless anyone raises any objections now.
Sebastien,
you
did the async work using PolicyBuilders and Interceptors so have you
any
comments to what I suggested in the email below?
...ant
On 6/6/06, ant elder [EMAIL PROTECTED] wrote:
I wondered about using Tuscany PolicyBuilders and Interceptors to
help
with E4X support for the work required in TUSCANY-418,
TUSCANY-419,
and
TUSCANY-420. Right now the E4X code isn't so elegant with the way
it
works
out when and how to convert the Java objects in a message into E4X
XML,
and
with the current code i can't get E4X XML as parameters on
reference
invocations working.
Looking at how the code for async works, it seems like for E4X
support
there could be source and target policy builders that look at the
wires
and
when required (*) insert an interceptor that converts the message
objects
from/to XmlObjects, and then the JavaScript container would simply
always
convert XmlObjects from/to E4X XML objects.
(*) the when required would be something like when the wire target
is
a
JavaScript component with interface described by a WSDL portType,
or a
wire
source is a JavaScript component and the wire target has an
interface
described with WSDL.
Does this sound like a reasonable use of PolicyBuilders and
Interceptors?
It seems like something like this may also be a step on the way to
the
efficient streaming of messages in TUSCANY-104?
...ant
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
Hi Ant,
I have been able to do the injection of required JS XmlObjects into the
script. The service invocation works fine.
I am now looking at the references part and am bit stuck there. There is a
problem in converting the javascript xml objects to the Java counterparts
(something that is being done in the RhinoInvoker for services side).
How are references injected into the javascript? Right now I understand
that, using the reference name as mentioned in the componentType file I am
able to access this object. But how did it get inject in the first place?
Please help with some info or pointers. Thanks.
- Venkat
On 8/23/06, ant elder [EMAIL PROTECTED] wrote:
I've had some offline chats with Venkat about this. I'd not ported any of
the E4X code over from M1 so Venkat is looking at that. The XML instance
utility being talked about is for JIRA TUSCANY-419. Here's a bit more
detail
on TUSCANY-419 and how it would work.
Today an E4X helloworld function looks like this:
function getGreeting(xmlIn) {
var greeting = e4xHello + xmlIn..*::in0;
var xmlOut =
helloworld:getGreetingsResponse xmlns:helloworld=
http://integration.rhino.container.tuscany.apache.org;
helloworld:getGreetingsReturn { greeting }
/helloworld:getGreetingsReturn
/helloworld:getGreetingsResponse;
return xmlOut;
}
There's a lot of boilerplate XML in there which could be determined
automatically from the WSDL, so ideally the function could rewritten
something like:
function getGreeting(xmlIn) {
var xmlOut = _getXML(getGreetingResponse);
xmlOut.getGreetingsReturn = e4xHello + xmlIn..*::in0;
return xmlOut;
}
The _getResponseXML function is a system supplied function that the
JavaScript container injects into the script environment. It returns an
E4X
XML object that is an representation of the WSDL schema with all the
values
defaulting. Thats worked out based on the interface of the component,
there
could be similar ones for references, eg, if there is a reference named
foo
you could do foo._getXML(fooType).
...ant
On 8/20/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Ant,
Is this something that works in M2 now? I remember doing a util for
creating xml instances for this.
When I see the current trunk's javascript container I don't see the e4x
samples. Shall I try moving them over and intergrating with the xml
instance creation utility. Please let me know.
Thanks.
- Venkat
On 6/7/06, ant elder [EMAIL PROTECTED] wrote:
No reply to this yet...after a little playing around it seems to work
so
I'm
going to go ahead unless anyone raises any objections now. Sebastien,
you
did the async work using PolicyBuilders and Interceptors so have you
any
comments to what I suggested in the email below?
...ant
On 6/6/06, ant elder [EMAIL PROTECTED] wrote:
I wondered about using Tuscany PolicyBuilders and Interceptors to
help
with E4X support for the work required in TUSCANY-418, TUSCANY-419,
and
TUSCANY-420. Right now the E4X code isn't so elegant with the way it
works
out when and how to convert the Java objects in a message into E4X
XML,
and
with the current code i can't get E4X XML as parameters on reference
invocations working.
Looking at how the code for async works, it seems like for E4X
support
there could be source and target policy builders that look at the
wires
and
when required (*) insert an interceptor that converts the message
objects
from/to XmlObjects, and then the JavaScript container would simply
always
convert XmlObjects from/to E4X XML objects.
(*) the when required would be something like when the wire target
is
a
JavaScript component with interface described by a WSDL portType, or
a
wire
source is a JavaScript component and the wire target has an
interface
described with WSDL.
Does this sound like a reasonable use of PolicyBuilders and
Interceptors?
It seems like something like this may also be a step on the way to
the
efficient streaming of messages in TUSCANY-104?
...ant
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
I've had some offline chats with Venkat about this. I'd not ported any of
the E4X code over from M1 so Venkat is looking at that. The XML instance
utility being talked about is for JIRA TUSCANY-419. Here's a bit more detail
on TUSCANY-419 and how it would work.
Today an E4X helloworld function looks like this:
function getGreeting(xmlIn) {
var greeting = e4xHello + xmlIn..*::in0;
var xmlOut =
helloworld:getGreetingsResponse xmlns:helloworld=
http://integration.rhino.container.tuscany.apache.org;
helloworld:getGreetingsReturn { greeting }
/helloworld:getGreetingsReturn
/helloworld:getGreetingsResponse;
return xmlOut;
}
There's a lot of boilerplate XML in there which could be determined
automatically from the WSDL, so ideally the function could rewritten
something like:
function getGreeting(xmlIn) {
var xmlOut = _getXML(getGreetingResponse);
xmlOut.getGreetingsReturn = e4xHello + xmlIn..*::in0;
return xmlOut;
}
The _getResponseXML function is a system supplied function that the
JavaScript container injects into the script environment. It returns an E4X
XML object that is an representation of the WSDL schema with all the values
defaulting. Thats worked out based on the interface of the component, there
could be similar ones for references, eg, if there is a reference named foo
you could do foo._getXML(fooType).
...ant
On 8/20/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Ant,
Is this something that works in M2 now? I remember doing a util for
creating xml instances for this.
When I see the current trunk's javascript container I don't see the e4x
samples. Shall I try moving them over and intergrating with the xml
instance creation utility. Please let me know.
Thanks.
- Venkat
On 6/7/06, ant elder [EMAIL PROTECTED] wrote:
No reply to this yet...after a little playing around it seems to work so
I'm
going to go ahead unless anyone raises any objections now. Sebastien,
you
did the async work using PolicyBuilders and Interceptors so have you any
comments to what I suggested in the email below?
...ant
On 6/6/06, ant elder [EMAIL PROTECTED] wrote:
I wondered about using Tuscany PolicyBuilders and Interceptors to help
with E4X support for the work required in TUSCANY-418, TUSCANY-419,
and
TUSCANY-420. Right now the E4X code isn't so elegant with the way it
works
out when and how to convert the Java objects in a message into E4X
XML,
and
with the current code i can't get E4X XML as parameters on reference
invocations working.
Looking at how the code for async works, it seems like for E4X support
there could be source and target policy builders that look at the
wires
and
when required (*) insert an interceptor that converts the message
objects
from/to XmlObjects, and then the JavaScript container would simply
always
convert XmlObjects from/to E4X XML objects.
(*) the when required would be something like when the wire target is
a
JavaScript component with interface described by a WSDL portType, or a
wire
source is a JavaScript component and the wire target has an interface
described with WSDL.
Does this sound like a reasonable use of PolicyBuilders and
Interceptors?
It seems like something like this may also be a step on the way to the
efficient streaming of messages in TUSCANY-104?
...ant
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
Hi Ant, Is this something that works in M2 now? I remember doing a util for creating xml instances for this. When I see the current trunk's javascript container I don't see the e4x samples. Shall I try moving them over and intergrating with the xml instance creation utility. Please let me know. Thanks. - Venkat On 6/7/06, ant elder [EMAIL PROTECTED] wrote: No reply to this yet...after a little playing around it seems to work so I'm going to go ahead unless anyone raises any objections now. Sebastien, you did the async work using PolicyBuilders and Interceptors so have you any comments to what I suggested in the email below? ...ant On 6/6/06, ant elder [EMAIL PROTECTED] wrote: I wondered about using Tuscany PolicyBuilders and Interceptors to help with E4X support for the work required in TUSCANY-418, TUSCANY-419, and TUSCANY-420. Right now the E4X code isn't so elegant with the way it works out when and how to convert the Java objects in a message into E4X XML, and with the current code i can't get E4X XML as parameters on reference invocations working. Looking at how the code for async works, it seems like for E4X support there could be source and target policy builders that look at the wires and when required (*) insert an interceptor that converts the message objects from/to XmlObjects, and then the JavaScript container would simply always convert XmlObjects from/to E4X XML objects. (*) the when required would be something like when the wire target is a JavaScript component with interface described by a WSDL portType, or a wire source is a JavaScript component and the wire target has an interface described with WSDL. Does this sound like a reasonable use of PolicyBuilders and Interceptors? It seems like something like this may also be a step on the way to the efficient streaming of messages in TUSCANY-104? ...ant
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
Raymond and I are having a discussion about this he is working on the data binding framework which will enable doing this. You should sync with him as I believe this will entail adding an E4X extension. Jim On Aug 20, 2006, at 5:51 AM, Venkata Krishnan wrote: Hi Ant, Is this something that works in M2 now? I remember doing a util for creating xml instances for this. When I see the current trunk's javascript container I don't see the e4x samples. Shall I try moving them over and intergrating with the xml instance creation utility. Please let me know. Thanks. - Venkat On 6/7/06, ant elder [EMAIL PROTECTED] wrote: No reply to this yet...after a little playing around it seems to work so I'm going to go ahead unless anyone raises any objections now. Sebastien, you did the async work using PolicyBuilders and Interceptors so have you any comments to what I suggested in the email below? ...ant On 6/6/06, ant elder [EMAIL PROTECTED] wrote: I wondered about using Tuscany PolicyBuilders and Interceptors to help with E4X support for the work required in TUSCANY-418, TUSCANY-419, and TUSCANY-420. Right now the E4X code isn't so elegant with the way it works out when and how to convert the Java objects in a message into E4X XML, and with the current code i can't get E4X XML as parameters on reference invocations working. Looking at how the code for async works, it seems like for E4X support there could be source and target policy builders that look at the wires and when required (*) insert an interceptor that converts the message objects from/to XmlObjects, and then the JavaScript container would simply always convert XmlObjects from/to E4X XML objects. (*) the when required would be something like when the wire target is a JavaScript component with interface described by a WSDL portType, or a wire source is a JavaScript component and the wire target has an interface described with WSDL. Does this sound like a reasonable use of PolicyBuilders and Interceptors? It seems like something like this may also be a step on the way to the efficient streaming of messages in TUSCANY-104? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
Yes, as Jim said, we're working on the databinding framework to support pluggable databindings and transformation on the wire. I'm not sure if you notice that there's a databinding-xmlbeans project and it would be nice that you can contribute the databinding-e4x. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, August 20, 2006 8:41 AM Subject: Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support Raymond and I are having a discussion about this he is working on the data binding framework which will enable doing this. You should sync with him as I believe this will entail adding an E4X extension. Jim On Aug 20, 2006, at 5:51 AM, Venkata Krishnan wrote: Hi Ant, Is this something that works in M2 now? I remember doing a util for creating xml instances for this. When I see the current trunk's javascript container I don't see the e4x samples. Shall I try moving them over and intergrating with the xml instance creation utility. Please let me know. Thanks. - Venkat On 6/7/06, ant elder [EMAIL PROTECTED] wrote: No reply to this yet...after a little playing around it seems to work so I'm going to go ahead unless anyone raises any objections now. Sebastien, you did the async work using PolicyBuilders and Interceptors so have you any comments to what I suggested in the email below? ...ant On 6/6/06, ant elder [EMAIL PROTECTED] wrote: I wondered about using Tuscany PolicyBuilders and Interceptors to help with E4X support for the work required in TUSCANY-418, TUSCANY-419, and TUSCANY-420. Right now the E4X code isn't so elegant with the way it works out when and how to convert the Java objects in a message into E4X XML, and with the current code i can't get E4X XML as parameters on reference invocations working. Looking at how the code for async works, it seems like for E4X support there could be source and target policy builders that look at the wires and when required (*) insert an interceptor that converts the message objects from/to XmlObjects, and then the JavaScript container would simply always convert XmlObjects from/to E4X XML objects. (*) the when required would be something like when the wire target is a JavaScript component with interface described by a WSDL portType, or a wire source is a JavaScript component and the wire target has an interface described with WSDL. Does this sound like a reasonable use of PolicyBuilders and Interceptors? It seems like something like this may also be a step on the way to the efficient streaming of messages in TUSCANY-104? ...ant - 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]
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
No reply to this yet...after a little playing around it seems to work so I'm going to go ahead unless anyone raises any objections now. Sebastien, you did the async work using PolicyBuilders and Interceptors so have you any comments to what I suggested in the email below? ...ant On 6/6/06, ant elder [EMAIL PROTECTED] wrote: I wondered about using Tuscany PolicyBuilders and Interceptors to help with E4X support for the work required in TUSCANY-418, TUSCANY-419, and TUSCANY-420. Right now the E4X code isn't so elegant with the way it works out when and how to convert the Java objects in a message into E4X XML, and with the current code i can't get E4X XML as parameters on reference invocations working. Looking at how the code for async works, it seems like for E4X support there could be source and target policy builders that look at the wires and when required (*) insert an interceptor that converts the message objects from/to XmlObjects, and then the JavaScript container would simply always convert XmlObjects from/to E4X XML objects. (*) the when required would be something like when the wire target is a JavaScript component with interface described by a WSDL portType, or a wire source is a JavaScript component and the wire target has an interface described with WSDL. Does this sound like a reasonable use of PolicyBuilders and Interceptors? It seems like something like this may also be a step on the way to the efficient streaming of messages in TUSCANY-104? ...ant
