aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Osborne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ARIES-47) Add interceptor concept to aries blueprint.
Date Wed, 18 Nov 2009 08:33:39 GMT

    [ 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.


Mime
View raw message