The other area we need to address for the service interceptor is that we may not want it to engage with half of the method interception. For an example, an interceptor comes in the interim of method invocation, we don't want it to engage in our post call. We also need to handle the situation of where an interceptor disappears in the interim of pre-call and post-call. This can be a bit tricky.
Many thanks and kindest regards, Emily From: "Joe Bohn (JIRA)" <[email protected]> To: [email protected] Date: 01/10/2010 04:55 Subject: [jira] Commented: (ARIES-420) Leverage Whiteboard pattern for interceptors [ 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. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
