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" <[EMAIL PROTECTED]>
To: <tuscany-dev@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: [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]
