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 Tue, 15 Dec 2009 12:49:18 GMT

    [ https://issues.apache.org/jira/browse/ARIES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790727#action_12790727
] 

Andrew Osborne commented on ARIES-47:
-------------------------------------

Interesting, with the asm approach, it would let us intercept a much wider range of beans,
looks simple enough to extend to the new Service Reference interceptors coming in via ARIES-84
too, and would likely be a good candidate to use for the internal Service Reference proxying.
It would make sense to centralize the proxying code too. I'll raise a JIRA to coordinate the
work, unless there are any objections I'll get started on it once ARIES-84 closes out.

> 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
>         Attachments: asm_subclass_proxy_patch.txt
>
>
> 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