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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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]
