[
https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916462#action_12916462
]
Joe Bohn edited comment on ARIES-420 at 9/30/10 9:17 AM:
---------------------------------------------------------
General idea at the moment:
1) Interceptors would be registered as services that support the Interceptor
interface.
2) Bean interceptors would be registered using service properties to designate
the specific beans that should leverage the interceptor (using bundle-id &
bean-id)
3) Service interceptors should likewise be registered using service properties
to designate the specific services (bundle-id & service-id)
4) Some consideration should be given to global interceptors - perhaps using
some other service property to indicate this or perhaps wild card support in
specification of the bundle-id and/or component-id - but this could become
complicated. This is a secondary goal at the moment.
5) When constructing a bean or service the service registry would be queried
for applicable interceptors
6) Serivce rank would be leveraged to property order the interceptors
7) The proxy will be constructed with the appropriate interceptors and a
service tracker to manage the potential dynamic nature of interceptors being
introduced or removed from the system.
For specific implementations like the transaction interceptor - it may be
necessary to indicate mandatory versus optional interceptor dependencies. This
would be the responsibility of the namespace handler that is processing the
custom tags. It determines that an interceptor is necessary and dynamically
creates the service registry entry for the interceptor. To enforce a mandatory
interceptor a service reference to the interceptor service can be added to the
bundle being parsed by the namespace handler.
was (Author: jbohn):
General idea at the moment:
1) Interceptors would be registered as services that support the Interceptor
interface.
2) Bean interceptors would be registered using service properties to designate
the specific beans that should leverage the interceptor (using bundle-id &
bean-id)
3) Service interceptors should likewise be registered using service properties
to designate the specific services (bundle-id & service-id)
4) Some consideration should be given to global interceptors - perhaps using
some other service property to indicate this or perhaps wild card support in
specification of the bundle-id and/or component-id - but this could become
complicated. This is a secondary goal at the moment.
5) When constructing a bean or service the service registry would be queried
for applicable interceptors
6) Serivce rank would be leveraged to property order the interceptors
7) The proxy will be constructed with the appropriate interceptors and a
service tracker to manage the potential dynamic nature of interceptors being
introduced or removed from the system.
> Leverage Whiteboard pattern for interceptors
> --------------------------------------------
>
> Key: ARIES-420
> URL: https://issues.apache.org/jira/browse/ARIES-420
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
> Affects Versions: 0.3
> Reporter: Joe Bohn
> Assignee: Joe Bohn
>
> Our current interceptor implementation is dependent upon registering a pojo
> for the interceptor with the component metadata. When constructing a bean
> (or service in the case of the newly introduced quiesce service interceptor)
> we retrieve the interceptor pojo(s) and use it in construction of the proxy.
> There are potential lifecycle issues with this if the bundle which introduced
> the interceptor is later removed from the system. A whiteboard pattern would
> improve lifecycle management such that the bundle dependencies can be better
> managed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
