Comments inline, hope its not becoming hard to read. ...ant
On 6/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Jun 22, 2006, at 2:00 AM, ant elder wrote: > I've come across difficulties related to this in the work I've done > with > extensions: > > - I tried adding another interface type a while back in M1 to have an > interface.smd to support the Dojo Simple Method Description for the > AJAX > binding (http://dojo.jot.com/SMD). I couldn't get it to work as the > current > code really didn't seem to be designed to support additional interface > types. > > - Another problem already touched on here and earlier in this > thread by Jim > is that right now the logical representation is a Java interfaces and > java.lang.Method is used to represent invocations. Because of this > I've not > yet been able to get a component to be able to call a reference using > non-Java parameters, eg the JavaScript component invoking a > reference using > E4X objects. (there's a testcase trying to do this in the rhino > container in > my sandbox if you're interested in more details) > O.K. I'll take a look but it may take a few days as I'm supposed to be on vacation but still have a backlog of work to take care of too. Quick questions: - You are talking about E4XServiceRefsTestCase?
Yes - HelloWorldProxyImpl flows an invoke to HelloWorldComponent2b which
is another JavaScript component but the intent/point is the target can be anything?
Component HelloWorldComponentE4XProxy has impl tests/HelloWorldE4XProxyImpl.js which is wired to component HelloWorldComponentE4X which has impl tests/e4x.js and tests/e4x.js uses interface.wsdl in its .componentType side file. Right now to use E4X objects the interface must be a WSDL interface. -An interceptor is interposed in the invocation to handle data
transformation (in this case it could be optimized away since it is a js-->js invoke)?
Yes. Not sure the interceptor is the right approach, I just tried this as i couldn't get the other way to work (see below) - Is SDO needed in the interceptor or is that something you just used
for expediency to do a conversion?
Just for expediency. Its the only databinding code we have right now that can transform XML bytes into typed Java Objects. ( org.apache.tuscany.databinding.sdo.SDOXMLHelper) This is going to bring up some interesting questions regarding
policy. I'm wondering if the target invoker should be doing the transformation as opposed to an interceptor and the target invoker could just use the data transformation service Raymond was working on?
Yes. I did try that approach with the M1 extension SPIs but without rewriting/duplicating a Iot of code I couldn't get at enough of the config to be able to setup the SDO databinding correctly. Eg, from somewhere like JavaScriptContextFactoryBuilder or JavaScriptContextFactory it needs to be able to see there is reference which has a WSDLServiceContract and get at the WSDL Definition. This is partly because right now it only works with E4X parameters when the service or reference is typed with a WSDL portType ( interface.wsdl). That seemed like an ok restriction to me at the time. An interesting issue is if that is the case (or even if we have
an interceptor do the transformation), how do we deal with a policy interceptor or handler that operates on the body of the messages? Raymond, would this be a two step process?
Is it possible in Rhino to take an E4X object and pass it by
reference to a JS target? In SCA, we assume pass-by-ref semantics within a shared memory space and it would be cool if we could optimize this. Also, it would be interesting if we could do pass-by- reference from Javascript to Java somehow (e.g. does E4X maintain some type of backing XML representation that could be passed)?
The actual JavaScript/E4X Rhino object is a org.mozilla.javascript.xml.XMLObject. Thats backed by an XmlBeans org.apache.xmlbeans.XmlObject. I guess ideally JS to JS would pass the XMLObject, but in the JS to Java case it could pass it either the XmlObject or use some databinding to convert the XML to a Java representation.
- Also related to this is the message format, transformation and > multiple > databinding support thats being discussed in other threads and > JIRAs. Should > a component or binding be able to put whatever type of object it > likes into > the message payload and have the Tuscany runtime sort out > transforming it as > required by other component types? I think we should look at taking Raymond's transformer and making it a system service rather than having the core directly have this knowledge. This way, it compartmentalizes the complexity and allows people to swap it out in favor of a different approach if they require it. > Right now thats not possible and each > binding and component must always use the Java types from the > logical Java > interface representation for the payload. > > None of these 3 things are possible with either the current code or > the > sandbox code and extension APIs and AFAICT it would be non-trivial > to fix. > While not trivial, I don't think this would be too drastic of a change to the sandbox code. The hardest part I think will be coming up with a representation that is usable and not overly complicated (like what we had before switching to Method). > Do we want to support any of these in M2? I'd really like to > support at > least the middle one. Regardless of whether we have an M2 or not n the short-term, I definitely think this is something we need to figure out ASAP. > > ...ant > > On 6/22/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> Jean-Sebastien Delfino wrote: >> > - The whole interface definition space, like you said we need a >> nice way >> > to deal with Java and WSDL interfaces, we also need to >> understand how >> > somebody can extend Tuscany to provide support for additional >> interface >> > definition languages (e.g. a ruby base class or a ruby module). >> >> We originally had a logical representation for this and changed >> part way >> through M1 to using Java interfaces (bytecode generating them from >> the >> WSDL definition when necessary). >> >> Do you think we should stick with the pure-Java approach (with >> addition >> annotations if necessary) or are you thinking of going back to a >> logical >> representation? >> >> -- >> Jeremy >> >> --------------------------------------------------------------------- >> 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]
