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]
