You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Greg Dritschler <gr...@us.ibm.com> on 2006/08/04 20:49:23 UTC
adding an interceptor
I am trying to understand how to add an interceptor to an invocation chain.
It looks like at one point this was accomplished by a implementing a
TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
However in the current code base it looks to me like the
PolicyBuilderRegistry is no longer instantiated. Is this broken or has
this been replaced by some other mechanism?
Greg Dritschler
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Application logging, was: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
I was thinking the integration would be needed by extensions (SPI) as
opposed to apps. My initial inclination is to limit the number of
things we expose but if someone feels strongly to keep it there I'm
probably not going to object because it will save me the trouble of
refactoring it out.
Jim
On Aug 27, 2006, at 3:44 PM, Jeremy Boynes wrote:
> Why restrict to just system stuff? Apps can still use log4j or
> jsr47 if they want but by making @Monitor available to them they
> can also integrate with Tuscany's framework.
>
> --
> Jeremy
>
> On Aug 27, 2006, at 3:38 PM, Jim Marino wrote:
>
>> My slight preference is to err on the side of caution and just
>> have it for system stuff now. For apps, I'd just recommend Log4J
>> and use an appender to pipe messages where they need to go.
>>
>> Jim
>>
>>
>> On Aug 27, 2006, at 3:14 PM, Jeremy Boynes wrote:
>>
>>> On Aug 23, 2006, at 1:08 PM, Jim Marino wrote:
>>>> O.K. I'll add this into API. Looking at the API package, I'm not
>>>> sure why @Monitor is defined there as I think that should be in
>>>> SPI. I believe Jeremy moved it there, so I'll have to ask him.
>>>
>>> I thought it might be used by application code as well.
>>> --
>>> Jeremy
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Application logging, was: adding an interceptor
Posted by Jeremy Boynes <jb...@apache.org>.
Why restrict to just system stuff? Apps can still use log4j or jsr47
if they want but by making @Monitor available to them they can also
integrate with Tuscany's framework.
--
Jeremy
On Aug 27, 2006, at 3:38 PM, Jim Marino wrote:
> My slight preference is to err on the side of caution and just have
> it for system stuff now. For apps, I'd just recommend Log4J and use
> an appender to pipe messages where they need to go.
>
> Jim
>
>
> On Aug 27, 2006, at 3:14 PM, Jeremy Boynes wrote:
>
>> On Aug 23, 2006, at 1:08 PM, Jim Marino wrote:
>>> O.K. I'll add this into API. Looking at the API package, I'm not
>>> sure why @Monitor is defined there as I think that should be in
>>> SPI. I believe Jeremy moved it there, so I'll have to ask him.
>>
>> I thought it might be used by application code as well.
>> --
>> Jeremy
>>
>> ---------------------------------------------------------------------
>> 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: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
My slight preference is to err on the side of caution and just have
it for system stuff now. For apps, I'd just recommend Log4J and use
an appender to pipe messages where they need to go.
Jim
On Aug 27, 2006, at 3:14 PM, Jeremy Boynes wrote:
> On Aug 23, 2006, at 1:08 PM, Jim Marino wrote:
>> O.K. I'll add this into API. Looking at the API package, I'm not
>> sure why @Monitor is defined there as I think that should be in
>> SPI. I believe Jeremy moved it there, so I'll have to ask him.
>
> I thought it might be used by application code as well.
> --
> Jeremy
>
> ---------------------------------------------------------------------
> 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: adding an interceptor
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 23, 2006, at 1:08 PM, Jim Marino wrote:
> O.K. I'll add this into API. Looking at the API package, I'm not
> sure why @Monitor is defined there as I think that should be in
> SPI. I believe Jeremy moved it there, so I'll have to ask him.
I thought it might be used by application code as well.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 23, 2006, at 10:38 AM, Raymond Feng wrote:
> Hi,
>
> I already have such an annotation defined in the databinding-
> framework module. We probably want to rename it as DataType to be
> consistent with the DataType model.
>
O.K. I'll add this into API. Looking at the API package, I'm not sure
why @Monitor is defined there as I think that should be in SPI. I
believe Jeremy moved it there, so I'll have to ask him.
> As for the two different annotation styles, I had some discussions
> with Jeremy. Here're some issues we touched:
>
> 1) The annotation can be used to create/decorate a DataType
> 2) The generic annotation should be able to catch all the related
> metadata for a given DataType (maybe some name/value pair for extra
> info)
> 3) We should allow databinding providers to add their own
> annotation if they choose to do so (I assume it's low proirity for
> now)
>
>
>> Also, some quick questions inline:
>>
>> On Aug 21, 2006, at 10:45 AM, Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> For the data transformation to be handled by a databinding
>>> interceptor, let's assume we have the following case:
>>>
>>> * The source side uses SDO.
>>>
>>> <import.sdo location="xsd/customer.xsd"/>
>>> int getCreditScore(@databinding.sdo(namespace="http://
>>> customer" name="Customer")Customer customer);
>>>
>> Is data binding definable per param, with the possibility to mix
>> or do we want to just say for the entire method (mixing seems
>> kind of strange). Also, what about the return value? Maybe it
>> would be better to place the param only on the method?
>>
>
> This concern was brought up by Ant as well. We have three levels
> here: Interface, Method and Parameter. Jeremy's DataType model
> seems to promote Parameter level. I think it's reasonable to set
> some defaults at Interface or Method level.
Is there a realistic case where people mix data types within an
operation? That seems kind of weird. Perhaps we just start with
interface and method level?
>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please my comments in line.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, August 23, 2006 10:16 AM
Subject: Re: adding an interceptor
> Are you proposing the use of "databinding." the package name for the
> annotations or does that have some significance? If it is just a package
> name, I'd assume we would want a fully qualified one. If this is the
> case, then an interesting question comes up - which one to use. Since
> these are extensions, I don't think we should allow the use of "Tuscany"
> for data binding extensions not provided by the project. Also, if we go
> this route, we'll need annotation processors for each annotation.
>
Sorry, it was a mistake in the sample. I meant two different annotations
such as "DataBindingSDO" and "DataBindingJAXB".
> Another option may be to define a generic "databinding" annotation such
> as:
>
> @Target({METHOD})
> @Retention(RUNTIME)
> public @interface Databinding {
>
> String type() default "";
>
> }
>
> Individual extensions would supply a value for type (its too bad enums
> can't be extended). There would be one annotation processor which would
> handle the decoration of the model. What do you think?
>
I already have such an annotation defined in the databinding-framework
module. We probably want to rename it as DataType to be consistent with the
DataType model.
As for the two different annotation styles, I had some discussions with
Jeremy. Here're some issues we touched:
1) The annotation can be used to create/decorate a DataType
2) The generic annotation should be able to catch all the related metadata
for a given DataType (maybe some name/value pair for extra info)
3) We should allow databinding providers to add their own annotation if they
choose to do so (I assume it's low proirity for now)
> Also, some quick questions inline:
>
> On Aug 21, 2006, at 10:45 AM, Raymond Feng wrote:
>
>> Hi,
>>
>> For the data transformation to be handled by a databinding interceptor,
>> let's assume we have the following case:
>>
>> * The source side uses SDO.
>>
>> <import.sdo location="xsd/customer.xsd"/>
>> int getCreditScore(@databinding.sdo(namespace="http://customer"
>> name="Customer")Customer customer);
>>
> Is data binding definable per param, with the possibility to mix or do we
> want to just say for the entire method (mixing seems kind of strange).
> Also, what about the return value? Maybe it would be better to place the
> param only on the method?
>
This concern was brought up by Ant as well. We have three levels here:
Interface, Method and Parameter. Jeremy's DataType model seems to promote
Parameter level. I think it's reasonable to set some defaults at Interface
or Method level.
>
>> * The target side uses JAXB.
>>
>> int getCreditScore(@databinding.jaxb Customer customer);
>>
>> Then the interceptor will require the following information:
>>
>> 1) DataType on the source side (SDO Customer)
>> 2) A "commonj.sdo.TypeHelper" associated with the current composite that
>> will provide the SDO type system
>> 3) DataType on the target side (JAXB Customer)
>> 4) (some JAXB context for the JAXB Customer?)
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jim Marino"
>> <jm...@myromatours.com>
>> To: <tu...@ws.apache.org>
>> Sent: Saturday, August 19, 2006 5:24 PM
>> Subject: Re: adding an interceptor
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
Are you proposing the use of "databinding." the package name for the
annotations or does that have some significance? If it is just a
package name, I'd assume we would want a fully qualified one. If this
is the case, then an interesting question comes up - which one to
use. Since these are extensions, I don't think we should allow the
use of "Tuscany" for data binding extensions not provided by the
project. Also, if we go this route, we'll need annotation processors
for each annotation.
Another option may be to define a generic "databinding" annotation
such as:
@Target({METHOD})
@Retention(RUNTIME)
public @interface Databinding {
String type() default "";
}
Individual extensions would supply a value for type (its too bad
enums can't be extended). There would be one annotation processor
which would handle the decoration of the model. What do you think?
Also, some quick questions inline:
On Aug 21, 2006, at 10:45 AM, Raymond Feng wrote:
> Hi,
>
> For the data transformation to be handled by a databinding
> interceptor, let's assume we have the following case:
>
> * The source side uses SDO.
>
> <import.sdo location="xsd/customer.xsd"/>
> int getCreditScore(@databinding.sdo(namespace="http://customer"
> name="Customer")Customer customer);
>
Is data binding definable per param, with the possibility to mix or
do we want to just say for the entire method (mixing seems kind of
strange). Also, what about the return value? Maybe it would be better
to place the param only on the method?
> * The target side uses JAXB.
>
> int getCreditScore(@databinding.jaxb Customer customer);
>
> Then the interceptor will require the following information:
>
> 1) DataType on the source side (SDO Customer)
> 2) A "commonj.sdo.TypeHelper" associated with the current composite
> that will provide the SDO type system
> 3) DataType on the target side (JAXB Customer)
> 4) (some JAXB context for the JAXB Customer?)
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Saturday, August 19, 2006 5:24 PM
> Subject: Re: adding an interceptor
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Raymond Feng <en...@gmail.com>.
Hi,
For the data transformation to be handled by a databinding interceptor,
let's assume we have the following case:
* The source side uses SDO.
<import.sdo location="xsd/customer.xsd"/>
int getCreditScore(@databinding.sdo(namespace="http://customer"
name="Customer")Customer customer);
* The target side uses JAXB.
int getCreditScore(@databinding.jaxb Customer customer);
Then the interceptor will require the following information:
1) DataType on the source side (SDO Customer)
2) A "commonj.sdo.TypeHelper" associated with the current composite that
will provide the SDO type system
3) DataType on the target side (JAXB Customer)
4) (some JAXB context for the JAXB Customer?)
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Saturday, August 19, 2006 5:24 PM
Subject: Re: adding an interceptor
>
> On Aug 19, 2006, at 3:44 PM, Raymond Feng wrote:
>
>> Hi, Jim.
>>
>> Thank you for the quick response. Please see my comments inline.
>>
>> Raymond
>>
>> ----- Original Message ----- From: "Jim Marino"
>> <jm...@myromatours.com>
>> To: <tu...@ws.apache.org>
>> Sent: Saturday, August 19, 2006 10:29 AM
>> Subject: Re: adding an interceptor
>>
>>
>>>
>>> On Aug 19, 2006, at 9:52 AM, Raymond Feng wrote:
>>>
>>>> Hi,
>>>>
>>>> I gave a try and got an interceptor added to the invocation using the
>>>> policy registry strategy. I reached a step (with some hacks/
>>>> workarounds) that the interceptors are able to be invoked with the
>>>> Echo binding sample.
>>>>
>>>> Here are a list of questions (some of them have been mentioned in
>>>> Jim's note) which will help me move forward.
>>>>
>>>> 1) We have a basic PolicyRegistry but it's not triggered to invoke
>>>> the policy builders by the core. I hacked JDKWireService to activate
>>>> it since I'm seeing some TODOs related to policy handling in the
>>>> code. I don't think it's the right place. Maybe it should be in the
>>>> connector?
>>>>
>>> It only needs to be added as a system service in the SCDL and
>>> autowired to the wire service. Did you try that?
>>
>> Well, my builders (which in turn add interceptors/handlers) can be added
>> to the policy registry which is created as a system service. The problem
>> I had is that even though the builders were registered with the
>> registry, they were not invoked since there's no code asked the policy
>> registry to do so.
>
> Right. I'm doing some changes there so I will add the invoke.
>
>>
>>>
>>>> 2) I had to change the InvocationChain SPI so that I can added the
>>>> interceptor before the InvokerInterceptor. Please see my post
>>>> (http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
>>>> 200608.mbox/%3c00af01c6bfd2$67649440$6aa24109@RFENGXP%3e).
>>>>
>>> This is a hack related to not having the policy builder. If you fix 1,
>>> I believe this is not necessary.
>>>
>>
>> Based on the my comment above, we still need to fix it. Or are you
>> saying the InvokerInterceptor should be handled as part of the policy?
>>
> The invoker interceptor should be done as the last thing by the builder
> registry.
>
>>>> 3) How does a policy builder receive the context (for example, the
>>>> CompositeComponent and other policy-related stuff) and make them
>>>> available to the interceptors/handlers it contributes? I agree with
>>>> Jim that the SPI needs more work.
>>>>
>>> That would be off reference definition and service definition. I can't
>>> remember if policy has a concept of a component-wide policy that
>>> affects policy decorations on things like references. If so, we may
>>> need to pass the component definition as well. Do you know offhand?
>>>
>>
>> It seems that the SCA spec (the policy appendix has not been updated to
>> 0.96 level) always talk about interaction policies for bindings and
>> implmentation policies for impls. I assume policy can apply to
>> service/reference/implementation.
>>
>>> I'm having second thoughts about moving the policy building into the
>>> connector phase. I think that would mean we loose the separation of
>>> runtime artifacts from the model as composite components would have
>>> knowledge of the former, leading to something that is probably very
>>> messy. Also, thinking about it more, what I think you are trying to do
>>> is an analysis of a wire which is tightly coupled to source and
>>> target, while policy is more "loosely" coupled in that it just
>>> prescribes statements about the nature of a source or target without
>>> specific knowledge of both. As a preliminary thought, what if we added
>>> the ability to decorate InvocationChain with extensibility elements
>>> that were added by a policy builder. Then, in the connect phase, we
>>> have "optimizers" which come along and can insert or subtract
>>> additional interceptors before the connect is made? I'm not sure this
>>> is the right approach but do you agree on the problem propagating the
>>> model would cause?
>>
>> I'm not promoting to pass the model down to the interceptor. Instead,
>> just to want to make sure the interceptor will have enough context to
>> decide to how to enforce the policy. For example, the DataBinding
>> interceptor will require the source DataType (as well as some
>> databinding-speficic info) and the target DataType to transform the
>> data.
>>
> That's why I think we need to decorate the invocation chain. Since you
> need knowledge of *both* target and source, and policy requires knowledge
> of one or the other, I don't think this should be done as part of policy.
> I need to look into this more but I think there should be an optimization
> step where data binding interceptors are introduced. This would come
> after all policy is in place.
>
> Can you tell me the information you need to propagate from source and
> target?
>
>>>
>>>
>>> so, in terms of ordering, we should have a system service that does a
>>> sort called at the end. The default would be to do nothing an simply
>>> return. This will allow people to plug in a programmatic sorter if
>>> required since the phase approach doesn't always work.
>>>
>>
>> Sounds good to me.
>>
> O.K. I'll add that in.
>>>>
>
>
> ---------------------------------------------------------------------
> 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: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 19, 2006, at 3:44 PM, Raymond Feng wrote:
> Hi, Jim.
>
> Thank you for the quick response. Please see my comments inline.
>
> Raymond
>
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Saturday, August 19, 2006 10:29 AM
> Subject: Re: adding an interceptor
>
>
>>
>> On Aug 19, 2006, at 9:52 AM, Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> I gave a try and got an interceptor added to the invocation
>>> using the policy registry strategy. I reached a step (with some
>>> hacks/ workarounds) that the interceptors are able to be invoked
>>> with the Echo binding sample.
>>>
>>> Here are a list of questions (some of them have been mentioned
>>> in Jim's note) which will help me move forward.
>>>
>>> 1) We have a basic PolicyRegistry but it's not triggered to
>>> invoke the policy builders by the core. I hacked JDKWireService
>>> to activate it since I'm seeing some TODOs related to policy
>>> handling in the code. I don't think it's the right place. Maybe
>>> it should be in the connector?
>>>
>> It only needs to be added as a system service in the SCDL and
>> autowired to the wire service. Did you try that?
>
> Well, my builders (which in turn add interceptors/handlers) can be
> added to the policy registry which is created as a system service.
> The problem I had is that even though the builders were registered
> with the registry, they were not invoked since there's no code
> asked the policy registry to do so.
Right. I'm doing some changes there so I will add the invoke.
>
>>
>>> 2) I had to change the InvocationChain SPI so that I can added
>>> the interceptor before the InvokerInterceptor. Please see my post
>>> (http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
>>> 200608.mbox/%3c00af01c6bfd2$67649440$6aa24109@RFENGXP%3e).
>>>
>> This is a hack related to not having the policy builder. If you
>> fix 1, I believe this is not necessary.
>>
>
> Based on the my comment above, we still need to fix it. Or are you
> saying the InvokerInterceptor should be handled as part of the policy?
>
The invoker interceptor should be done as the last thing by the
builder registry.
>>> 3) How does a policy builder receive the context (for example,
>>> the CompositeComponent and other policy-related stuff) and make
>>> them available to the interceptors/handlers it contributes? I
>>> agree with Jim that the SPI needs more work.
>>>
>> That would be off reference definition and service definition. I
>> can't remember if policy has a concept of a component-wide policy
>> that affects policy decorations on things like references. If so,
>> we may need to pass the component definition as well. Do you know
>> offhand?
>>
>
> It seems that the SCA spec (the policy appendix has not been
> updated to 0.96 level) always talk about interaction policies for
> bindings and implmentation policies for impls. I assume policy can
> apply to service/reference/implementation.
>
>> I'm having second thoughts about moving the policy building into
>> the connector phase. I think that would mean we loose the
>> separation of runtime artifacts from the model as composite
>> components would have knowledge of the former, leading to
>> something that is probably very messy. Also, thinking about it
>> more, what I think you are trying to do is an analysis of a wire
>> which is tightly coupled to source and target, while policy is
>> more "loosely" coupled in that it just prescribes statements
>> about the nature of a source or target without specific knowledge
>> of both. As a preliminary thought, what if we added the ability
>> to decorate InvocationChain with extensibility elements that were
>> added by a policy builder. Then, in the connect phase, we have
>> "optimizers" which come along and can insert or subtract
>> additional interceptors before the connect is made? I'm not sure
>> this is the right approach but do you agree on the problem
>> propagating the model would cause?
>
> I'm not promoting to pass the model down to the interceptor.
> Instead, just to want to make sure the interceptor will have enough
> context to decide to how to enforce the policy. For example, the
> DataBinding interceptor will require the source DataType (as well
> as some databinding-speficic info) and the target DataType to
> transform the data.
>
That's why I think we need to decorate the invocation chain. Since
you need knowledge of *both* target and source, and policy requires
knowledge of one or the other, I don't think this should be done as
part of policy. I need to look into this more but I think there
should be an optimization step where data binding interceptors are
introduced. This would come after all policy is in place.
Can you tell me the information you need to propagate from source and
target?
>>
>>
>> so, in terms of ordering, we should have a system service that
>> does a sort called at the end. The default would be to do nothing
>> an simply return. This will allow people to plug in a
>> programmatic sorter if required since the phase approach doesn't
>> always work.
>>
>
> Sounds good to me.
>
O.K. I'll add that in.
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Raymond Feng <en...@gmail.com>.
Hi, Jim.
Thank you for the quick response. Please see my comments inline.
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Saturday, August 19, 2006 10:29 AM
Subject: Re: adding an interceptor
>
> On Aug 19, 2006, at 9:52 AM, Raymond Feng wrote:
>
>> Hi,
>>
>> I gave a try and got an interceptor added to the invocation using the
>> policy registry strategy. I reached a step (with some hacks/ workarounds)
>> that the interceptors are able to be invoked with the Echo binding
>> sample.
>>
>> Here are a list of questions (some of them have been mentioned in Jim's
>> note) which will help me move forward.
>>
>> 1) We have a basic PolicyRegistry but it's not triggered to invoke the
>> policy builders by the core. I hacked JDKWireService to activate it
>> since I'm seeing some TODOs related to policy handling in the code. I
>> don't think it's the right place. Maybe it should be in the connector?
>>
> It only needs to be added as a system service in the SCDL and autowired
> to the wire service. Did you try that?
Well, my builders (which in turn add interceptors/handlers) can be added to
the policy registry which is created as a system service. The problem I had
is that even though the builders were registered with the registry, they
were not invoked since there's no code asked the policy registry to do so.
>
>> 2) I had to change the InvocationChain SPI so that I can added the
>> interceptor before the InvokerInterceptor. Please see my post
>> (http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
>> 200608.mbox/%3c00af01c6bfd2$67649440$6aa24109@RFENGXP%3e).
>>
> This is a hack related to not having the policy builder. If you fix 1, I
> believe this is not necessary.
>
Based on the my comment above, we still need to fix it. Or are you saying
the InvokerInterceptor should be handled as part of the policy?
>> 3) How does a policy builder receive the context (for example, the
>> CompositeComponent and other policy-related stuff) and make them
>> available to the interceptors/handlers it contributes? I agree with Jim
>> that the SPI needs more work.
>>
> That would be off reference definition and service definition. I can't
> remember if policy has a concept of a component-wide policy that affects
> policy decorations on things like references. If so, we may need to pass
> the component definition as well. Do you know offhand?
>
It seems that the SCA spec (the policy appendix has not been updated to 0.96
level) always talk about interaction policies for bindings and implmentation
policies for impls. I assume policy can apply to
service/reference/implementation.
> I'm having second thoughts about moving the policy building into the
> connector phase. I think that would mean we loose the separation of
> runtime artifacts from the model as composite components would have
> knowledge of the former, leading to something that is probably very
> messy. Also, thinking about it more, what I think you are trying to do is
> an analysis of a wire which is tightly coupled to source and target,
> while policy is more "loosely" coupled in that it just prescribes
> statements about the nature of a source or target without specific
> knowledge of both. As a preliminary thought, what if we added the ability
> to decorate InvocationChain with extensibility elements that were added
> by a policy builder. Then, in the connect phase, we have "optimizers"
> which come along and can insert or subtract additional interceptors
> before the connect is made? I'm not sure this is the right approach but
> do you agree on the problem propagating the model would cause?
I'm not promoting to pass the model down to the interceptor. Instead, just
to want to make sure the interceptor will have enough context to decide to
how to enforce the policy. For example, the DataBinding interceptor will
require the source DataType (as well as some databinding-speficic info) and
the target DataType to transform the data.
>
>
>> 4) How do we decide that a policy interceptor/handler should be
>> activated for an invocation chain? I guess it's the policy builder's
>> repsonsibility and the decision will be made based on some metadata (for
>> example, the presence of SCDL for a given policy).
> This would be done by the particular policy builder. An interceptor or
> handler would never be introduced if it was not activated.
>>
>> 5) What's the ordering strategy for policy interceptors/handlers? Axis2
>> has the phase concept which we may steal.
> There was a preliminary phase concept in the policy builder registry
> which we should reconcile against Axis' concepts. Also, I'd be interested
> in understanding Celtix in this respect as they have done a lot with
> multiple transports. Dan, Jervis?
>
> Also, in terms of ordering, we should have a system service that does a
> sort called at the end. The default would be to do nothing an simply
> return. This will allow people to plug in a programmatic sorter if
> required since the phase approach doesn't always work.
>
Sounds good to me.
>>
>> 6) It seems now the policy can only apply to bound services and
>> references. Is it possible that we apply it for local wiring as well?
>>
> Sure we just need to plug in the policy builder.
>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jim Marino"
>> <jm...@myromatours.com>
>> To: <tu...@ws.apache.org>
>> Sent: Tuesday, August 08, 2006 7:18 PM
>> Subject: Re: adding an interceptor
>>
>>
>>> Hi Matthew,
>>>
>>> Sorry for the delay in answer, I've been swamped at work. This would
>>> be great if you could jump in. Generally we have a pattern of using a
>>> registry for various extensions (e.g. loaders, builders) that handle a
>>> particular task in the runtime. An extension would be contributed as a
>>> system service (implementation.system), and as it was initialized,
>>> would register itself with the registry (the extension gains a pointer
>>> to the registry by declaring an "autowire" to it - you may not be
>>> familiar with this mechanism so I'm happy to explain if so). The
>>> registry would then dispatch to the correct extension based on some
>>> key. For example, with the SCDL loaders, the loader registry uses the
>>> XML element name.
>>>
>>> I was thinking the policy registry would function the same way. There
>>> would be a registry that would track all of the policy extension
>>> points, source and target policy "builders". These extension points
>>> would be called to decorate either an inbound or outbound wire with
>>> interceptors or handlers. We may also want to have the concept of
>>> phases to help with ordering as well as a way for an extension
>>> developer to plug in a class that can order interceptors/handlers
>>> after all have been contributed to a wire.
>>>
>>> Currently, there is a very primitive cut at the policy registry
>>> (PolicyBuilderRegistryImpl) and policy builders (SourcePolicyBuilder
>>> and TargetPolicyBuilder). As a start, perhaps you could start looking
>>> at the current registry implementation and seeing what parts need
>>> refactoring? I believe the API needs some work. For example, related
>>> to the following methods on PolicyBuilderRegistry:
>>>
>>> void buildSource(ReferenceDefinition referenceDefinition, OutboundWire
>>> wire) throws BuilderException;
>>>
>>> void buildTarget(ServiceDefinition serviceDefinition, InboundWire
>>> wire) throws BuilderException;
>>>
>>> we currently use a Java class and java.lang.Method to represent the
>>> service interface and a service operation respectively. We need a
>>> generic way to represent Services and associated metadata such as
>>> asynchronicity and policy. There's an ongoing thread on that so we
>>> should pick up the details there, I just wanted to call your attention
>>> to it.
>>>
>>> I imagine as you start to look at this, you will have questions on how
>>> invocations flow, the relationship between inbound and outbound
>>> chains, and how interceptors and handlers work. Can you start to have
>>> a look at the registry and post questions as they arise?
>>>
>>> Thanks,
>>> Jim
>>>
>>>
>>>
>>> On Aug 7, 2006, at 6:23 AM, Matthew Sykes wrote:
>>>
>>>> Jim,
>>>>
>>>> I'd be interested in contributing to this but I'm not sure I know
>>>> exactly where to begin. If you're willing to spend a bit of time on
>>>> the Q&A necessary to describe the intended flow through the bindings,
>>>> wires invocation handlers, and policy handlers (using some of
>>>> Jeremy's presentation as a starting point), I'm in.
>>>>
>>>> Thanks.
>>>>
>>>> Jim Marino wrote:
>>>>> Greg,
>>>>> We don't have this finished yet but it would be a nice project for
>>>>> someone to work on, particularly since it would involve figuring out
>>>>> how we are going to support SCA policy. If you or someone else is
>>>>> interested in tackling this (or part of it) let me know and I'll
>>>>> help out.
>>>>> Jim
>>>>> On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
>>>>>> I am trying to understand how to add an interceptor to an
>>>>>> invocation chain.
>>>>>> It looks like at one point this was accomplished by a implementing a
>>>>>> TargetPolicyBuilder and registering it with the
>>>>>> PolicyBuilderRegistry.
>>>>>> However in the current code base it looks to me like the
>>>>>> PolicyBuilderRegistry is no longer instantiated. Is this broken or
>>>>>> has
>>>>>> this been replaced by some other mechanism?
>>>>>>
>>>>>> Greg Dritschler
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> -- -
>>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 19, 2006, at 9:52 AM, Raymond Feng wrote:
> Hi,
>
> I gave a try and got an interceptor added to the invocation using
> the policy registry strategy. I reached a step (with some hacks/
> workarounds) that the interceptors are able to be invoked with the
> Echo binding sample.
>
> Here are a list of questions (some of them have been mentioned in
> Jim's note) which will help me move forward.
>
> 1) We have a basic PolicyRegistry but it's not triggered to invoke
> the policy builders by the core. I hacked JDKWireService to
> activate it since I'm seeing some TODOs related to policy handling
> in the code. I don't think it's the right place. Maybe it should be
> in the connector?
>
It only needs to be added as a system service in the SCDL and
autowired to the wire service. Did you try that?
> 2) I had to change the InvocationChain SPI so that I can added the
> interceptor before the InvokerInterceptor. Please see my post
> (http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/
> 200608.mbox/%3c00af01c6bfd2$67649440$6aa24109@RFENGXP%3e).
>
This is a hack related to not having the policy builder. If you fix
1, I believe this is not necessary.
> 3) How does a policy builder receive the context (for example, the
> CompositeComponent and other policy-related stuff) and make them
> available to the interceptors/handlers it contributes? I agree with
> Jim that the SPI needs more work.
>
That would be off reference definition and service definition. I
can't remember if policy has a concept of a component-wide policy
that affects policy decorations on things like references. If so, we
may need to pass the component definition as well. Do you know offhand?
I'm having second thoughts about moving the policy building into the
connector phase. I think that would mean we loose the separation of
runtime artifacts from the model as composite components would have
knowledge of the former, leading to something that is probably very
messy. Also, thinking about it more, what I think you are trying to
do is an analysis of a wire which is tightly coupled to source and
target, while policy is more "loosely" coupled in that it just
prescribes statements about the nature of a source or target without
specific knowledge of both. As a preliminary thought, what if we
added the ability to decorate InvocationChain with extensibility
elements that were added by a policy builder. Then, in the connect
phase, we have "optimizers" which come along and can insert or
subtract additional interceptors before the connect is made? I'm not
sure this is the right approach but do you agree on the problem
propagating the model would cause?
> 4) How do we decide that a policy interceptor/handler should be
> activated for an invocation chain? I guess it's the policy
> builder's repsonsibility and the decision will be made based on
> some metadata (for example, the presence of SCDL for a given policy).
This would be done by the particular policy builder. An interceptor
or handler would never be introduced if it was not activated.
>
> 5) What's the ordering strategy for policy interceptors/handlers?
> Axis2 has the phase concept which we may steal.
There was a preliminary phase concept in the policy builder registry
which we should reconcile against Axis' concepts. Also, I'd be
interested in understanding Celtix in this respect as they have done
a lot with multiple transports. Dan, Jervis?
Also, in terms of ordering, we should have a system service that does
a sort called at the end. The default would be to do nothing an
simply return. This will allow people to plug in a programmatic
sorter if required since the phase approach doesn't always work.
>
> 6) It seems now the policy can only apply to bound services and
> references. Is it possible that we apply it for local wiring as well?
>
Sure we just need to plug in the policy builder.
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, August 08, 2006 7:18 PM
> Subject: Re: adding an interceptor
>
>
>> Hi Matthew,
>>
>> Sorry for the delay in answer, I've been swamped at work. This
>> would be great if you could jump in. Generally we have a pattern
>> of using a registry for various extensions (e.g. loaders,
>> builders) that handle a particular task in the runtime. An
>> extension would be contributed as a system service
>> (implementation.system), and as it was initialized, would
>> register itself with the registry (the extension gains a pointer
>> to the registry by declaring an "autowire" to it - you may not be
>> familiar with this mechanism so I'm happy to explain if so). The
>> registry would then dispatch to the correct extension based on
>> some key. For example, with the SCDL loaders, the loader registry
>> uses the XML element name.
>>
>> I was thinking the policy registry would function the same way.
>> There would be a registry that would track all of the policy
>> extension points, source and target policy "builders". These
>> extension points would be called to decorate either an inbound or
>> outbound wire with interceptors or handlers. We may also want to
>> have the concept of phases to help with ordering as well as a way
>> for an extension developer to plug in a class that can order
>> interceptors/handlers after all have been contributed to a wire.
>>
>> Currently, there is a very primitive cut at the policy registry
>> (PolicyBuilderRegistryImpl) and policy builders
>> (SourcePolicyBuilder and TargetPolicyBuilder). As a start,
>> perhaps you could start looking at the current registry
>> implementation and seeing what parts need refactoring? I believe
>> the API needs some work. For example, related to the following
>> methods on PolicyBuilderRegistry:
>>
>> void buildSource(ReferenceDefinition referenceDefinition,
>> OutboundWire wire) throws BuilderException;
>>
>> void buildTarget(ServiceDefinition serviceDefinition, InboundWire
>> wire) throws BuilderException;
>>
>> we currently use a Java class and java.lang.Method to represent
>> the service interface and a service operation respectively. We
>> need a generic way to represent Services and associated metadata
>> such as asynchronicity and policy. There's an ongoing thread on
>> that so we should pick up the details there, I just wanted to
>> call your attention to it.
>>
>> I imagine as you start to look at this, you will have questions
>> on how invocations flow, the relationship between inbound and
>> outbound chains, and how interceptors and handlers work. Can you
>> start to have a look at the registry and post questions as they
>> arise?
>>
>> Thanks,
>> Jim
>>
>>
>>
>> On Aug 7, 2006, at 6:23 AM, Matthew Sykes wrote:
>>
>>> Jim,
>>>
>>> I'd be interested in contributing to this but I'm not sure I know
>>> exactly where to begin. If you're willing to spend a bit of
>>> time on the Q&A necessary to describe the intended flow through
>>> the bindings, wires invocation handlers, and policy handlers
>>> (using some of Jeremy's presentation as a starting point), I'm in.
>>>
>>> Thanks.
>>>
>>> Jim Marino wrote:
>>>> Greg,
>>>> We don't have this finished yet but it would be a nice project
>>>> for someone to work on, particularly since it would involve
>>>> figuring out how we are going to support SCA policy. If you or
>>>> someone else is interested in tackling this (or part of it) let
>>>> me know and I'll help out.
>>>> Jim
>>>> On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
>>>>> I am trying to understand how to add an interceptor to an
>>>>> invocation chain.
>>>>> It looks like at one point this was accomplished by a
>>>>> implementing a
>>>>> TargetPolicyBuilder and registering it with the
>>>>> PolicyBuilderRegistry.
>>>>> However in the current code base it looks to me like the
>>>>> PolicyBuilderRegistry is no longer instantiated. Is this
>>>>> broken or has
>>>>> this been replaced by some other mechanism?
>>>>>
>>>>> Greg Dritschler
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -- -
>>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: adding an interceptor
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I gave a try and got an interceptor added to the invocation using the policy
registry strategy. I reached a step (with some hacks/workarounds) that the
interceptors are able to be invoked with the Echo binding sample.
Here are a list of questions (some of them have been mentioned in Jim's
note) which will help me move forward.
1) We have a basic PolicyRegistry but it's not triggered to invoke the
policy builders by the core. I hacked JDKWireService to activate it since
I'm seeing some TODOs related to policy handling in the code. I don't think
it's the right place. Maybe it should be in the connector?
2) I had to change the InvocationChain SPI so that I can added the
interceptor before the InvokerInterceptor. Please see my post
(http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/%3c00af01c6bfd2$67649440$6aa24109@RFENGXP%3e).
3) How does a policy builder receive the context (for example, the
CompositeComponent and other policy-related stuff) and make them available
to the interceptors/handlers it contributes? I agree with Jim that the SPI
needs more work.
4) How do we decide that a policy interceptor/handler should be activated
for an invocation chain? I guess it's the policy builder's repsonsibility
and the decision will be made based on some metadata (for example, the
presence of SCDL for a given policy).
5) What's the ordering strategy for policy interceptors/handlers? Axis2 has
the phase concept which we may steal.
6) It seems now the policy can only apply to bound services and references.
Is it possible that we apply it for local wiring as well?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, August 08, 2006 7:18 PM
Subject: Re: adding an interceptor
> Hi Matthew,
>
> Sorry for the delay in answer, I've been swamped at work. This would be
> great if you could jump in. Generally we have a pattern of using a
> registry for various extensions (e.g. loaders, builders) that handle a
> particular task in the runtime. An extension would be contributed as a
> system service (implementation.system), and as it was initialized, would
> register itself with the registry (the extension gains a pointer to the
> registry by declaring an "autowire" to it - you may not be familiar with
> this mechanism so I'm happy to explain if so). The registry would then
> dispatch to the correct extension based on some key. For example, with
> the SCDL loaders, the loader registry uses the XML element name.
>
> I was thinking the policy registry would function the same way. There
> would be a registry that would track all of the policy extension points,
> source and target policy "builders". These extension points would be
> called to decorate either an inbound or outbound wire with interceptors
> or handlers. We may also want to have the concept of phases to help with
> ordering as well as a way for an extension developer to plug in a class
> that can order interceptors/handlers after all have been contributed to a
> wire.
>
> Currently, there is a very primitive cut at the policy registry
> (PolicyBuilderRegistryImpl) and policy builders (SourcePolicyBuilder and
> TargetPolicyBuilder). As a start, perhaps you could start looking at the
> current registry implementation and seeing what parts need refactoring? I
> believe the API needs some work. For example, related to the following
> methods on PolicyBuilderRegistry:
>
> void buildSource(ReferenceDefinition referenceDefinition, OutboundWire
> wire) throws BuilderException;
>
> void buildTarget(ServiceDefinition serviceDefinition, InboundWire wire)
> throws BuilderException;
>
> we currently use a Java class and java.lang.Method to represent the
> service interface and a service operation respectively. We need a generic
> way to represent Services and associated metadata such as asynchronicity
> and policy. There's an ongoing thread on that so we should pick up the
> details there, I just wanted to call your attention to it.
>
> I imagine as you start to look at this, you will have questions on how
> invocations flow, the relationship between inbound and outbound chains,
> and how interceptors and handlers work. Can you start to have a look at
> the registry and post questions as they arise?
>
> Thanks,
> Jim
>
>
>
> On Aug 7, 2006, at 6:23 AM, Matthew Sykes wrote:
>
>> Jim,
>>
>> I'd be interested in contributing to this but I'm not sure I know
>> exactly where to begin. If you're willing to spend a bit of time on the
>> Q&A necessary to describe the intended flow through the bindings, wires
>> invocation handlers, and policy handlers (using some of Jeremy's
>> presentation as a starting point), I'm in.
>>
>> Thanks.
>>
>> Jim Marino wrote:
>>> Greg,
>>> We don't have this finished yet but it would be a nice project for
>>> someone to work on, particularly since it would involve figuring out
>>> how we are going to support SCA policy. If you or someone else is
>>> interested in tackling this (or part of it) let me know and I'll help
>>> out.
>>> Jim
>>> On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
>>>> I am trying to understand how to add an interceptor to an invocation
>>>> chain.
>>>> It looks like at one point this was accomplished by a implementing a
>>>> TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
>>>> However in the current code base it looks to me like the
>>>> PolicyBuilderRegistry is no longer instantiated. Is this broken or
>>>> has
>>>> this been replaced by some other mechanism?
>>>>
>>>> Greg Dritschler
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 10, 2006, at 3:13 PM, Raymond Feng wrote:
> Hi,
>
> I'm exploring the possibility to add interceptors to deal with data
> binding transformations. It seems that PolicyBuilder is one place
> that interceptors can be added to the invocation chain. Can other
> builders (such as component builders and binding builders)
> contribute interceptors as well? I read the code briefly and found
> out the wires are not connected when the builders are invoked.
Yes the interceptors are added before the connect phase. Do you need
knowledge of both ends of the wire? If so, we may have to look at
moving the PolicyBuilder into the connector, which wouldn't be that
big of a deal.
>
> Thanks,
> Raymond
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I'm exploring the possibility to add interceptors to deal with data binding
transformations. It seems that PolicyBuilder is one place that interceptors
can be added to the invocation chain. Can other builders (such as component
builders and binding builders) contribute interceptors as well? I read the
code briefly and found out the wires are not connected when the builders are
invoked.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, August 08, 2006 7:18 PM
Subject: Re: adding an interceptor
> Hi Matthew,
>
> Sorry for the delay in answer, I've been swamped at work. This would be
> great if you could jump in. Generally we have a pattern of using a
> registry for various extensions (e.g. loaders, builders) that handle a
> particular task in the runtime. An extension would be contributed as a
> system service (implementation.system), and as it was initialized, would
> register itself with the registry (the extension gains a pointer to the
> registry by declaring an "autowire" to it - you may not be familiar with
> this mechanism so I'm happy to explain if so). The registry would then
> dispatch to the correct extension based on some key. For example, with
> the SCDL loaders, the loader registry uses the XML element name.
>
> I was thinking the policy registry would function the same way. There
> would be a registry that would track all of the policy extension points,
> source and target policy "builders". These extension points would be
> called to decorate either an inbound or outbound wire with interceptors
> or handlers. We may also want to have the concept of phases to help with
> ordering as well as a way for an extension developer to plug in a class
> that can order interceptors/handlers after all have been contributed to a
> wire.
>
> Currently, there is a very primitive cut at the policy registry
> (PolicyBuilderRegistryImpl) and policy builders (SourcePolicyBuilder and
> TargetPolicyBuilder). As a start, perhaps you could start looking at the
> current registry implementation and seeing what parts need refactoring? I
> believe the API needs some work. For example, related to the following
> methods on PolicyBuilderRegistry:
>
> void buildSource(ReferenceDefinition referenceDefinition, OutboundWire
> wire) throws BuilderException;
>
> void buildTarget(ServiceDefinition serviceDefinition, InboundWire wire)
> throws BuilderException;
>
> we currently use a Java class and java.lang.Method to represent the
> service interface and a service operation respectively. We need a generic
> way to represent Services and associated metadata such as asynchronicity
> and policy. There's an ongoing thread on that so we should pick up the
> details there, I just wanted to call your attention to it.
>
> I imagine as you start to look at this, you will have questions on how
> invocations flow, the relationship between inbound and outbound chains,
> and how interceptors and handlers work. Can you start to have a look at
> the registry and post questions as they arise?
>
> Thanks,
> Jim
>
>
>
> On Aug 7, 2006, at 6:23 AM, Matthew Sykes wrote:
>
>> Jim,
>>
>> I'd be interested in contributing to this but I'm not sure I know
>> exactly where to begin. If you're willing to spend a bit of time on the
>> Q&A necessary to describe the intended flow through the bindings, wires
>> invocation handlers, and policy handlers (using some of Jeremy's
>> presentation as a starting point), I'm in.
>>
>> Thanks.
>>
>> Jim Marino wrote:
>>> Greg,
>>> We don't have this finished yet but it would be a nice project for
>>> someone to work on, particularly since it would involve figuring out
>>> how we are going to support SCA policy. If you or someone else is
>>> interested in tackling this (or part of it) let me know and I'll help
>>> out.
>>> Jim
>>> On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
>>>> I am trying to understand how to add an interceptor to an invocation
>>>> chain.
>>>> It looks like at one point this was accomplished by a implementing a
>>>> TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
>>>> However in the current code base it looks to me like the
>>>> PolicyBuilderRegistry is no longer instantiated. Is this broken or
>>>> has
>>>> this been replaced by some other mechanism?
>>>>
>>>> Greg Dritschler
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
Hi Matthew,
Sorry for the delay in answer, I've been swamped at work. This would
be great if you could jump in. Generally we have a pattern of using a
registry for various extensions (e.g. loaders, builders) that handle
a particular task in the runtime. An extension would be contributed
as a system service (implementation.system), and as it was
initialized, would register itself with the registry (the extension
gains a pointer to the registry by declaring an "autowire" to it -
you may not be familiar with this mechanism so I'm happy to explain
if so). The registry would then dispatch to the correct extension
based on some key. For example, with the SCDL loaders, the loader
registry uses the XML element name.
I was thinking the policy registry would function the same way. There
would be a registry that would track all of the policy extension
points, source and target policy "builders". These extension points
would be called to decorate either an inbound or outbound wire with
interceptors or handlers. We may also want to have the concept of
phases to help with ordering as well as a way for an extension
developer to plug in a class that can order interceptors/handlers
after all have been contributed to a wire.
Currently, there is a very primitive cut at the policy registry
(PolicyBuilderRegistryImpl) and policy builders (SourcePolicyBuilder
and TargetPolicyBuilder). As a start, perhaps you could start looking
at the current registry implementation and seeing what parts need
refactoring? I believe the API needs some work. For example, related
to the following methods on PolicyBuilderRegistry:
void buildSource(ReferenceDefinition referenceDefinition,
OutboundWire wire) throws BuilderException;
void buildTarget(ServiceDefinition serviceDefinition, InboundWire
wire) throws BuilderException;
we currently use a Java class and java.lang.Method to represent the
service interface and a service operation respectively. We need a
generic way to represent Services and associated metadata such as
asynchronicity and policy. There's an ongoing thread on that so we
should pick up the details there, I just wanted to call your
attention to it.
I imagine as you start to look at this, you will have questions on
how invocations flow, the relationship between inbound and outbound
chains, and how interceptors and handlers work. Can you start to have
a look at the registry and post questions as they arise?
Thanks,
Jim
On Aug 7, 2006, at 6:23 AM, Matthew Sykes wrote:
> Jim,
>
> I'd be interested in contributing to this but I'm not sure I know
> exactly where to begin. If you're willing to spend a bit of time
> on the Q&A necessary to describe the intended flow through the
> bindings, wires invocation handlers, and policy handlers (using
> some of Jeremy's presentation as a starting point), I'm in.
>
> Thanks.
>
> Jim Marino wrote:
>> Greg,
>> We don't have this finished yet but it would be a nice project for
>> someone to work on, particularly since it would involve figuring
>> out how we are going to support SCA policy. If you or someone
>> else is interested in tackling this (or part of it) let me know
>> and I'll help out.
>> Jim
>> On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
>>> I am trying to understand how to add an interceptor to an
>>> invocation chain.
>>> It looks like at one point this was accomplished by a implementing a
>>> TargetPolicyBuilder and registering it with the
>>> PolicyBuilderRegistry.
>>> However in the current code base it looks to me like the
>>> PolicyBuilderRegistry is no longer instantiated. Is this broken
>>> or has
>>> this been replaced by some other mechanism?
>>>
>>> Greg Dritschler
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: adding an interceptor
Posted by Matthew Sykes <sy...@gmail.com>.
Jim,
I'd be interested in contributing to this but I'm not sure I know
exactly where to begin. If you're willing to spend a bit of time on the
Q&A necessary to describe the intended flow through the bindings, wires
invocation handlers, and policy handlers (using some of Jeremy's
presentation as a starting point), I'm in.
Thanks.
Jim Marino wrote:
> Greg,
>
> We don't have this finished yet but it would be a nice project for
> someone to work on, particularly since it would involve figuring out how
> we are going to support SCA policy. If you or someone else is
> interested in tackling this (or part of it) let me know and I'll help out.
>
> Jim
>
>
> On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
>
>> I am trying to understand how to add an interceptor to an invocation
>> chain.
>> It looks like at one point this was accomplished by a implementing a
>> TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
>> However in the current code base it looks to me like the
>> PolicyBuilderRegistry is no longer instantiated. Is this broken or has
>> this been replaced by some other mechanism?
>>
>> Greg Dritschler
>>
>>
>> ---------------------------------------------------------------------
>> 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: adding an interceptor
Posted by Jim Marino <jm...@myromatours.com>.
Greg,
We don't have this finished yet but it would be a nice project for
someone to work on, particularly since it would involve figuring out
how we are going to support SCA policy. If you or someone else is
interested in tackling this (or part of it) let me know and I'll help
out.
Jim
On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:
> I am trying to understand how to add an interceptor to an
> invocation chain.
> It looks like at one point this was accomplished by a implementing a
> TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
> However in the current code base it looks to me like the
> PolicyBuilderRegistry is no longer instantiated. Is this broken or
> has
> this been replaced by some other mechanism?
>
> Greg Dritschler
>
>
> ---------------------------------------------------------------------
> 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