[
https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916768#action_12916768
]
Joe Bohn commented on ARIES-420:
--------------------------------
Thanks for the comments Valentin. This is still a general idea ... so there
may be some rough edges. I'm learning more as I attempt to get this working
in my private trunk image. I may check what I have in to sandbox or somewhere
as soon as I have enough working that it is worthwhile.
Regarding interceptors going away (presumably because the bundle that contains
the interceptor was removed) ... I believe that adding the service reference to
the bundle of the intercepted bean and then using that to get the service
reference will wire the bundles together such that the Blueprint will wait for
an interceptor to come back and timeout if it does not become available.
Regarding dynamic interceptors ... that is really just some recent thoughts at
this point in time. I'm currently working with interceptors introduced via
namespaces (as you expect) - so that is the main priority.
I do not yet know how or if we would handle dynamic interceptors - but I was
thinking that we might be able to register a bean interceptor as a service
using blueprint xml and specifying the beanid as a property (bundle id would be
more of an issue if the interceptor must be that specific and may make dynamic
interceptors impossible if it is a requirement). However, if beanid is enough
we could create a service tracker for each bean to listen for Interceptors
registered with a matching beanid (regardless of bundles) and these could then
come and go dynamically. They would have to be optional. The only reason I
even started thinking about interceptors that aren't registered via a namespace
was because of the recently added quiesce service interceptor and another JIRA
that was opened to allow additional service interceptors. The quiesce one
isn't registered by a namespace handler and others might not be either. It
might just make more sense for service interceptors and not bean interceptors
... but I think the mechanism to locate and leverage interceptors could be
similar between bean and service interceptors and might make things more
flexible for beans as well as services (or it may be a bust).
> 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.
