You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2007/02/07 18:27:22 UTC
DataBindingInterceptor and PassByValueInterceptor question
Hi,
In the process of refactoring core, I'm attempting to remove the need
for Wire.getContainer(). Two places this is used is
DataBindingInterceptor and PassByValueInterceptor. The former tunnels
up to the wire container's parent and passes the CompositeComponent
as metadata in the transformation context but does not appear to be
used (or at least it's not used in kernel or explicitly called out in
a typed API). Why do we need to do this?
Similarly, PassByValueInterceptor performs a Wire.getContainer on the
target wire and attempts to downcast it to AtomicComponent so that it
can call AtomicComponent.isAllowsPassByReference(). The
AtomicComponent.isAllowsPassByReference() I don't think should exist
at all since allows-pass-by-reference is an service operation-related
quality, i.e. a component implementation may offer multiple services
some of which may contain a mix of operations that allow and/or do
not allow by-reference.
I'd like to remove the use of Wire.getContainer from
DataBindingInterceptor and not pass the composite as context
information unless there is a good reason to do so (it should also
probably be done through a typed API if so).
For PassByValueInterceptor, I'd like to remove this check as well
since the behavior is not correct and later implement metadata that
is added to the service contract Operation.
If people working in these areas can let me know if I've overlooked
something I would appreciate it.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DataBindingInterceptor and PassByValueInterceptor question
Posted by Raymond Feng <en...@gmail.com>.
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" <fo...@gmail.com>
To: <tu...@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 <en...@gmail.com> 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" <jm...@myromatours.com>
>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DataBindingInterceptor and PassByValueInterceptor question
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <en...@gmail.com> 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" <jm...@myromatours.com>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: DataBindingInterceptor and PassByValueInterceptor question
Posted by Raymond Feng <en...@gmail.com>.
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" <jm...@myromatours.com>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DataBindingInterceptor and PassByValueInterceptor question
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DataBindingInterceptor and PassByValueInterceptor question
Posted by Raymond Feng <en...@gmail.com>.
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.
Here's an example using import.sdo:
In the SCDL, we use the <import.sdo>.
<composite ...>
<dbsdo:import.sdo .../>
...
</composite>
ImportSDO loader will create a model object for the element out of the StAX
events. And the ImportSDO builder (or resolver?) will use the model to
populate SDO types in the TypeHelper which is assoicated/scoped with the
CompositeComponent. The SDO transformer requires the TypeHelper for the
current composite to perform the transformation.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, February 07, 2007 9:27 AM
Subject: DataBindingInterceptor and PassByValueInterceptor question
> Hi,
>
> In the process of refactoring core, I'm attempting to remove the need for
> Wire.getContainer(). Two places this is used is DataBindingInterceptor
> and PassByValueInterceptor. The former tunnels up to the wire container's
> parent and passes the CompositeComponent as metadata in the
> transformation context but does not appear to be used (or at least it's
> not used in kernel or explicitly called out in a typed API). Why do we
> need to do this?
>
> Similarly, PassByValueInterceptor performs a Wire.getContainer on the
> target wire and attempts to downcast it to AtomicComponent so that it can
> call AtomicComponent.isAllowsPassByReference(). The
> AtomicComponent.isAllowsPassByReference() I don't think should exist at
> all since allows-pass-by-reference is an service operation-related
> quality, i.e. a component implementation may offer multiple services some
> of which may contain a mix of operations that allow and/or do not allow
> by-reference.
>
> I'd like to remove the use of Wire.getContainer from
> DataBindingInterceptor and not pass the composite as context information
> unless there is a good reason to do so (it should also probably be done
> through a typed API if so).
>
> For PassByValueInterceptor, I'd like to remove this check as well since
> the behavior is not correct and later implement metadata that is added to
> the service contract Operation.
>
> If people working in these areas can let me know if I've overlooked
> something I would appreciate it.
>
> Jim
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org