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


Reply via email to