No, it looks like the InterfaceImpl types no longer implement Cloneable though I remember the old version of this function did support clone(). Scott.
On 7/6/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, I think the clone() has already been supported. Thanks, Raymond ----- Original Message ----- From: "Scott Kurz" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, July 06, 2007 8:41 AM Subject: Re: Problems using WSDL interfaces together with DataBinding (DB) framework > After thinking on this a bit, I wonder if I was confusing things by > wrongly > coupling the question of Java vs. WSDL interface with the choice of > DataBinding. > > Say I wanted the java.lang.Object DB for my binding. I could still set > this up on the binding-level operation objects, whether I had a Java or > WSDL > interface. > > It's not as if by using a WSDL interface I'm tied to using something like > an > AXIOM DB. > > Right? > > So I guess this is still a simple pattern binding impls could use. > > A separate issue though is the question of whether we should be able to > clone (2) at the level of (3) instead of writing to the same object. I > think these used > to be clonable... > > Scott > > > On 7/6/07, Simon Laws <[EMAIL PROTECTED]> wrote: >> >> On 7/6/07, Scott Kurz <[EMAIL PROTECTED]> wrote: >> > >> > Raymond, >> > >> > Your proposal makes sense to me. >> > >> > It seems like a nice simplification to view the component-level intf >> > (2) >> > as >> > existing only for testing >> > wire-mappability of interfaces and to view the "componentType intf", >> > (or >> > impl-level intf) (1) and >> > the binding intf (3) as the interfaces with databindings associated >> > with >> > them. >> > >> > Would you agree one consequence of such a change, though, would be that >> > binding impl like the default binding impl whose method impl: >> > >> > RuntimeSCABindingProvider.getBindingInterfaceContract() >> > >> > merely delegates to the >> > >> > RuntimeComponentReference.getInterfaceContract() >> > >> > would have to be reconsidered? >> > >> > This code setting up interface (3) on the binding might prefer to copy >> > interface (1) rather than (2), maybe for the specific purpose of >> > wanting >> > to >> > use a Java, not a WSDL interface. >> > >> > Actually the code as written today does not always do the job of >> > setting >> > up >> > a Java interface (if that is the goal), as the component could have a >> > Composite impl with WSDL interface on the Composite-level ref/service. >> > The >> > code setting up the binding intf (3) might really want a Java atomic >> > component impl's Java intf to percolate up to be set on the binding. >> > (Maybe a WSDL->Java conversion is the right thing to do here then). >> > >> > Anyway, I'm expanding the discussion a bit ... >> > >> > I need to think a bit to articulate in more detail some questions I >> still >> > have ... so I'll stop here. >> > Thanks, >> > Scott >> > >> > >> > >> > >> > >> > >> > >> > You've thought about this more than I have.. but >> > >> > >> > >> > On 7/5/07, Raymond Feng <[EMAIL PROTECTED]> wrote: >> > > >> > > Hi, Scott. >> > > >> > > Thank you for bringing up this issue. I have been thinking about this >> > for >> > > a >> > > while:-). >> > > >> > > There are three interfaces in the picture: >> > > >> > > 1) [componentType.reference.interface]: The java interface of the >> > > reference >> > > defined by the component type, which is introspected from the >> @Reference >> > > annotation on the java class >> > > (GreetingComponentImpl). This is the effective interface what the >> > outbound >> > > call made. For example, >> > > >> > > Reference declaration: >> > > @Reference >> > > protected HelloWorld helloWorldService; >> > > >> > > Reference usage: >> > > helloWorldService.hello(...); >> > > >> > > 2) [component.reference.interface]: The wsdl interface that overrides >> > the >> > > reference for "MyComponent". This interface is for purpose of wiring. >> In >> > > most cases, the interface for >> > > the reference on the component is the same as the one for the >> reference >> > on >> > > the component type. >> > > >> > > 3) [component.reference.binding.interface] The wsdl interface that >> > > the >> > WS >> > > binding uses, i.e., the portType for >> > HelloWorldService/HelloWorldSoapPort. >> > > This is the effective interface that binding layer expects to receive >> > > data. >> > > >> > > The data transformation should happen between the interface 1 and >> > > interface >> > > 3 (instead of 2 and 3). >> > > >> > > The same happens to the service side. If we have a java component, >> > > the >> > > interface for the service on the component type is a java >> > interface/class. >> > > When the component service is further typed with interface.wsdl, then >> > the >> > > interface for the service on the component is a WSDL interface. But >> the >> > > one >> > > for the component type should be used for data transformation >> purposes. >> > > >> > > So I think the solution is to use the interface for reference on the >> > > component type to perform the data transformation. >> > > >> > > Do you agree? >> > > >> > > Thanks, >> > > Raymond >> > > >> > > ----- Original Message ----- >> > > From: "Scott Kurz" <[EMAIL PROTECTED]> >> > > To: <[email protected]> >> > > Sent: Tuesday, July 03, 2007 4:40 AM >> > > Subject: Problems using WSDL interfaces together with DataBinding >> > > (DB) >> > > framework >> > > >> > > >> > > > Say I use SCDL like (for WS binding): >> > > > >> > > > <component name="MyComponent"> >> > > > <implementation.java class=" >> > > > test.sca.w2j.ws.static_sdo.helloworld.GreetingComponentImpl"/> >> > > > <reference name="helloWorldService"> >> > > > <interface.wsdl interface=" >> > > > >> > > >> > >> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.interface(HelloWorld) >> > > > "/> >> > > > <binding.ws wsdlElement=" >> > > > >> > > >> > >> http://w2j.sca.soa.ws/test/hw-ws-static-sdo-2parm#wsdl.port(HelloWorldService/HelloWorldSoapPort) >> > > > "/> >> > > > </reference> >> > > > </component> >> > > > >> > > > If I rely on the DefaultWSDLInterfaceIntrospector to build the >> > Operation >> > > > model objects for the Component-level Interface, they will be >> created >> > > with >> > > > a >> > > > null DB, because of the null in: >> > > > >> > > > WSDLOperation op = new WSDLOperation(wsdlFactory, wsdlOp, >> > > > inlineSchemas, >> > > > null, resolver); >> > > > >> > > > This leads to the following exception as I try to convert between >> the >> > > null >> > > > DB at the component level and the AXIOM DB set by the WS binding at >> > the >> > > > binding level. >> > > > >> > > > org.apache.tuscany.sca.databinding.TransformationException: No >> wrapper >> > > > handler is provided for databinding: null >> > > > at >> > > > >> > > >> > >> org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.getWrapperHandler >> > > > (Input2InputTransformer.java:204) >> > > > at >> > > > >> > > >> > >> org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform >> > > > (Input2InputTransformer.java:112) >> > > > at >> > > > >> > > >> > >> org.apache.tuscany.core.databinding.transformers.Input2InputTransformer.transform >> > > > (Input2InputTransformer.java:53) >> > > > at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate( >> > > > MediatorImpl.java:77) >> > > > at >> > > > >> > > >> > >> org.apache.tuscany.core.databinding.wire.DataTransformationInteceptor.transform >> > > > (DataTransformationInteceptor.java:168) >> > > > >> > > > >> > > > So I tried setting up the Axiom DB instead from >> > > > DefaultWSDLInterfaceIntrospector on the component-level-interface >> > > > Operation >> > > > objects loaded from <interface.wsdl> definitions. (Note I had to >> > > > workaround >> > > > JIRA TUSCANY-1342 with the fix I suggested). >> > > > >> > > > This change has the side effect, however, of causing >> > > > DataTransformationInteceptor to not get set up when I'm using the >> > > > WS >> > > > binding, since the WS binding uses the Axiom DB and since the >> > > > DataBindingRuntimeWireProcessor won't create the interceptor in the >> > case >> > > > the >> > > > DBs match. >> > > > >> > > > Does someone have a better idea of how to make the DataBinding >> > framework >> > > > do >> > > > what I want here? >> > > > >> > > > Looking at this I'm wondering... did we lose a DB "layer" in the >> move >> > to >> > > > 1.0-spec code? Before we had component-level, composite-level and >> > > > binding-level. Now we have only component-level and >> binding-level. >> > > > >> > > > Is a DB Interceptor needed to transform between the impl level and >> the >> > > > component level in a case like this where you have a Java impl w/ >> SDO >> > DB >> > > > but >> > > > you put <interface.wsdl> on the component-level service/ref? >> > > > >> > > > (One might ask what is the point of using <interface.wsdl> at all >> > > > in >> a >> > > > case >> > > > like this, since the WS binding can convert between different, >> > > compatible >> > > > Java interfaces on either side. Well, I'm looking ahead to the >> time >> > > > when >> > > > we have a wire between a ref w/ WS binding and a service w/ WS >> binding >> > > and >> > > > < >> > > > interface.wsdl> would allow us to easily determine interface >> > > compatibility >> > > > on the wire.) >> > > > >> > > > Scott >> > > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> > > >> > > >> > >> I'm not sure I have much to offer to this conversation just yet but I'm >> interested in the context of making the SCA Binding a first class citizen >> in >> order to support both local and remote invocation scenarios. As Scott >> says >> the way it sits as the moment is that it follows the original implement >> and >> defers to interface [2] when asked for the interface contract. >> >> In the case where no binding has been specified the suggestion that >> interface [1] should provide the interface contract fits well. Does the >> model already make this assumption? >> >> Simon >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
