Great stuff, this makes things much simpler. I've moved the JSON-RPC binding
over to this API now which is fairly trivial but FWIW here are a few
comments:
1) Is there anyway to avoid requiring the @Scope("MODULE") annotation on the
EntryPointBuilderSupport subclass? Its easy to forget and not obvious whats
wrong when you do.
2) Wouldn't it be simpler if handlesBindingType returned the binding class
instead of a boolean so all the logic could be in EntryPointBuilderSupport?
3) Could there be a default implementation of
EntryPointBuilderSupport.createEntryPointContextFactory which returns the
EntryPointContextFactory impl in the core? Neither the Axis2 or JSONRPC
bindings add any function to that.
4) Instead of being protected should the fields builderRegistry, wireService
and messageFactory in EntryPointBuilderSupport be private and have getter
methods? This class is becoming like an SPI so getters would give a bit
more flexibility if something needs to be changed later.
...ant
On 4/26/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> I've added the extension APIs to core for the following:
>
> - Bindings (entry points/external services)
> - Component types (atomic/composite)
> - Policy
>
> There are two basic levels, "simple" and "advanced". The simple
> approach, which is designed for the "80%" case, involves extending
> one of four support classes in core/extension. This approach hides as
> much of the infrastructure as possible. I would like to iterate over
> the API design since I am sure it will need to be changed as we
> encounter different use cases. I would also like to eventually
> automate creation of extension points further by creating IDE
> templates which produce many of the extension classes, since quite a
> few are wrote. The more advanced, or low-level, API can be released
> later as we gain confidence in the design since it exposes more
> capabilities.
>
> For example, with the simple approach, one needs to do the following
> to implement a component type (the most complex scenario). The
> description is also probably more complex than the code:
>
> 1. Write the assembly artifacts and loader as described on the wiki
>
> 2. Extend ContextFactoryBuilderSupport, overriding the
> createContextFactory method, which passes back the ContextFactory for
> the component type. JavaContextFactoryBuilder is an example, which is
> a little more complex than it needs to be due to processing of
> annotations for things like init and destroy, which I intend to
> remove in refactorings today.
>
> 3. Write a Context and ContextFactory implementation. The
> ContextFactory implementation is used by the runtime to create
> configured Contexts, which manage component implementation instances.
>
> The ContextFactory will be passed properties (name, object value) and
> wire factories. Wire factories are either of type SourceWireFactory
> or TargetWireFactory, corresponding to outgoing wires for a reference
> and incoming wires for a service respectively. Source and target
> invocation chains (per operation) are connected by the runtime to
> form a wire between two of the following: entry point, external
> service, or component. If a non-component client calls locateService,
> they will be returned a proxy fronting just the TargetWireFactory
> invocation chains. The ContextFactory must take those factories and
> pass them to a Context which "connects" them to the component
> implementation instance. For example, the Java support wraps source
> wire factories in an ObjectFactory which is used by an Injector to
> create a proxy that is injected into a method or field on the
> component implementation class. The proxy creation method is located
> on WireFactory, the base class for SourceWireFactory and
> TargetWireFactory.
>
> 3. Write a TargetInvoker implementation and extend
> WireBuilderSupport, overriding createInvoker. The latter creates the
> TargetInvoker, which is responsible for dispatching to an instance of
> the component type. This class also contains another method,
> handlesTargetType, which signals to the runtime which component
> implementation type the wire builder creates target invokers for. I
> intend to eliminate this as it may be reflected through generics. The
> TargetInvoker interface is pretty simple, one has to implement
> invokeTarget and clone.
>
> For component implementation types, a target invoker will generally
> take the scope context the component is associated with and resolve
> the component instance against it when it receives an invocation. The
> TargetInvoker may cache the resolved result if the source is of a
> lesser scope than the target (this information is passed into the
> WireBuilder). Don't cache resolves when going from a greater to
> lesser scope since that will result in "crossed" contexts. Clone is
> necessary since TargetInvokers are cached on the source side of a
> wire per operation and passed through both
> source and target invokcation chains, where it is "invoked" by the
> last interceptor in the target chain. TargetInvoker.clone() is called
> by the proxy invocation handler (e.g. JDKInvocationHandler) if the
> target invoker caches invocations on the first invoke of the
> operation and held there. Otherwise it uses a "stateless invoker".
> This allows us to optimize resolves away for sources of a lesser
> scope. All of this is probably more detail than a component
> implementor will need to be aware of since the extension classes
> abstract this away.
>
> 4. Contribute the loader, ContextFactory, and WireBuilder
> implementations as a system module (along with the TargetInvoker
> class). They will automagically be registered in the runtime and
> everything should just work.
>
> Please take a look and provide feedback.
>
> Jim
>
