[
https://issues.apache.org/jira/browse/ARIES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779368#action_12779368
]
Andrew Osborne commented on ARIES-47:
-------------------------------------
The interceptor's intent is just to be able to see the method call being
placed, and the return (or failure) of that invocation. It should not be able
to affect the call proceeding just as it would if the interceptor(s) were
absent. In this manner it's similar to say, telephone interception.
Would be interesting to allow Beans to be declared as interceptors in the xml,
and to use an attribute to tag them to other beans, but there are many
questions that would need to be resolved before attempting this. For the moment
the Interceptors are configured via NamespaceHandlers (or, in theory a
ComponentDefinitionRegistryProcessor).
In the simplest form, a custom ns handler can be invoked for an attribute, or
element of a bean definition, and can use the parsercontext to obtain the
enclosing bean metadata, then register an interceptor against it.
> Add interceptor concept to aries blueprint.
> -------------------------------------------
>
> Key: ARIES-47
> URL: https://issues.apache.org/jira/browse/ARIES-47
> Project: Aries
> Issue Type: New Feature
> Components: Blueprint
> Reporter: Andrew Osborne
> Assignee: Andrew Osborne
>
> Add support for 'interceptors' to Aries blueprint.
> The concept is to allow interceptors to be configured for a bean, so that
> whenever invocations are made to methods on the bean, the interceptors are
> notified before the call, and after the call.
> An interceptors intent is not to modify the arguments to the call, or the
> return from the call, but merely to be notified, and to be able to inspect
> the arguments that were passed (if any), and the response/exception returned
> (if any).
> Interceptor would be added as a new Interface, at the same level as
> BeanProcessor, and the ComponentDefinitionRegistry enhanced to allow
> Interceptors to be registered against BeanMetadata.
> NamespaceHandlers will be able to add interceptors via the ParserContext when
> invoked to handle custom elements/attributes.
> Interceptors would 'see' : The bean metadata for the invocation, The method
> being / that-was invoked, and any Arguments/Return data/Exceptions.
> Interceptors would be implemented by dynamically creating a subclass of the
> bean that wrappers the original instance of the bean, replacing the bean in
> the blueprint container.
> (CGlib looks interesting for the dynamic subclass, although potentially
> problematic regarding classes without default zero-arg constructors, if not
> cglib, then lower using the asm library instead)
> The dynamic subclass will coordinate invoking the interceptors, and the
> delegation of the call to the instance of the bean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
