Thanks Raymond. Yes, I am aware of the fact that this should be picked up from the Implementation and hence was guessing the ImplementationProcessor to be the place for picking this up. Anyways, I guess I can figure that out :)
- Venkat On 2/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, I guess I need to correct my previous response. The @AllowsPassByReference should be used to annotate the implementation class/method instead of the interface. Then the flag should goes to the Java implementation. The following is quoted from the Java C&I spec: ===================== The @AllowsPassByReference annotation is used on implementations of remotable interfaces to indicate that interactions with the service within the same address space are allowed to use pass by reference data exchange semantics. The implementation promises that its by-value semantics will be maintained even if the parameters and return values are actually passed by-reference. This means that the service will not modify any operation input parameter or return value, even after returning from the operation. Either a whole class implementing a remotable service or the individual remotable service method implementation can be annotated using the @AllowsPassByReference annotation. ====================== Thanks, Raymond ----- Original Message ----- From: "Raymond Feng" <[EMAIL PROTECTED]> To: <tuscany-dev@ws.apache.org> Sent: Thursday, February 08, 2007 8:23 AM Subject: Re: DataBindingInterceptor and PassByValueInterceptor question > Hi, Venkat. > > I think it's reasonable to add an attribute "allowsPassByReference" to the > Operation model. We already have "remotable" in the ServiceContract. The > java introspection can set the attribute. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Venkata Krishnan" <[EMAIL PROTECTED]> > To: <tuscany-dev@ws.apache.org> > Sent: Thursday, February 08, 2007 4:37 AM > Subject: Re: DataBindingInterceptor and PassByValueInterceptor question > > >> Hi Jim, >> >> The PassByValueWirePostProcessor sure needs an update in the sense that >> it >> only looks for allowsPassByReference at the interface level. It needs to >> do >> this at the operation level as well. >> >> My imagination is to have this information as part of 'Operation' which >> presently has things like isNonBlocking, isCallBack and so on. So >> something >> like 'isAllowsPassByReference'. If this is right, then is this >> something >> that we must do in the ImplementationProcessor i.e. looking for the >> allowsPassByReference annotation and setting this to the Operation >> instance. >> >> Let me know if I can go ahead and do this. Thanks. >> >> - Venkat >> >> >> On 2/8/07, Raymond Feng <[EMAIL PROTECTED]> wrote: >>> >>> Yes, I agree. And that should be part of the efforts to support the >>> load/resolve/build for SCDL extensibility elements so that they can be >>> handled in a pluggable way. >>> >>> Thanks, >>> Raymond >>> >>> ----- Original Message ----- >>> From: "Jim Marino" <[EMAIL PROTECTED]> >>> To: <tuscany-dev@ws.apache.org> >>> Sent: Wednesday, February 07, 2007 10:37 AM >>> Subject: Re: DataBindingInterceptor and PassByValueInterceptor question >>> >>> >>> > >>> > On Feb 7, 2007, at 10:21 AM, Raymond Feng wrote: >>> > >>> >> Hi, Jim. >>> >> >>> >> Let me explain the DataBindingInterceptor part. >>> >> >>> >> In this case, I pass the CompositeComponent as a metadata in the >>> >> transformation context so that the transformers can access the >>> >> extensions (SCAObject.getExtensions) of the CompositeComponent. The >>> >> extensions contain some information (such as the TypeHelper for the >>> >> composite) built from SCDL extensibility elements such as >>> >> <import.sdo >>> >. >>> >> This is a workaround to support the load/build for SCDL >>> >> extensibility >>> >> elements. >>> >> >>> > >>> > Thanks Raymond for the response... >>> > >>> > This seems problematic, particularly since we are passing >>> > CompositeComponent just to use extensibility elements in an >>> untyped way. >>> > Wouldn't it be better to do this through some type of typed context ( >>> e.g. >>> > for extensibility elements, which themselves may need to be untyped) >>> for >>> > the post processor? I generally prefer APIs to be explicit about what >>> > they are passing around. >>> > >>> > Jim >>> > >>> > --------------------------------------------------------------------- >>> > 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] >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
