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/[EMAIL PROTECTED]).
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" <[EMAIL PROTECTED]>
To: <[email protected]>
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: [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]
---------------------------------------------------------------------
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]
