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]
