You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Joe Bohn (JIRA)" <ji...@apache.org> on 2010/09/22 15:46:32 UTC
[jira] Created: (ARIES-420) Register interceptors as services and
add a service reference to applicable bean
Register interceptors as services and add a service reference to applicable bean
--------------------------------------------------------------------------------
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (ARIES-420) Leverage Whiteboard pattern for
interceptors
Posted by Emily Jiang <EM...@uk.ibm.com>.
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)" <ji...@apache.org>
To: aries-dev@incubator.apache.org
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
[jira] Commented: (ARIES-420) Leverage Whiteboard pattern for
interceptors
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (ARIES-420) Leverage Whiteboard
pattern for interceptors
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ 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:08 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.
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 element-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.
[jira] Work started: (ARIES-420) Register Bean Interceptors as
Services
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on ARIES-420 started by Joe Bohn.
> Register Bean Interceptors as Services
> ---------------------------------------
>
> 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.
[jira] Updated: (ARIES-420) Leverage Whiteboard pattern for
interceptors
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joe Bohn updated ARIES-420:
---------------------------
Summary: Leverage Whiteboard pattern for interceptors (was: Register interceptors as services and add a service reference to applicable bean)
Description: 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.
> 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.
[jira] Commented: (ARIES-420) Leverage Whiteboard pattern for
interceptors
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916462#action_12916462 ]
Joe Bohn commented on ARIES-420:
--------------------------------
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 element-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.
[jira] Updated: (ARIES-420) Register Bean Interceptors as Services
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joe Bohn updated ARIES-420:
---------------------------
Summary: Register Bean Interceptors as Services (was: Leverage Whiteboard pattern for interceptors)
> Register Bean Interceptors as Services
> ---------------------------------------
>
> 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.
[jira] Issue Comment Edited: (ARIES-420) Leverage Whiteboard
pattern for interceptors
Posted by "Joe Bohn (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (ARIES-420) Leverage Whiteboard pattern for
interceptors
Posted by "Valentin Mahrwald (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916739#action_12916739 ]
Valentin Mahrwald commented on ARIES-420:
-----------------------------------------
I like the sounds of it, but am not entirely sold on the potential new lifecycle bits :)
What happens when a (mandatory) interceptor goes away during the lifetime of the bean? Does the bean still get intercepted with the previously retrieved interceptor, does it not get intercepted or does Blueprint start to wait for an interceptor to come back?
Also how would a bean specific interceptor be dynamically introduced. As far as it happens now interceptors are a by product of namespace handlers being called. This happens only once, so it wouldn't be dynamic. Would a newly started interceptor provider examine existing Blueprint containers?
> 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.