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"
<[EMAIL PROTECTED]>
To: <[email protected]>
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/[EMAIL PROTECTED]).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
