[
https://issues.apache.org/jira/browse/ARIES-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Osborne reassigned ARIES-27:
-----------------------------------
Assignee: Andrew Osborne
> Expand the BeanProcessor interface, so it is better able to make decisions
> about bean replacements.
> ---------------------------------------------------------------------------------------------------
>
> Key: ARIES-27
> URL: https://issues.apache.org/jira/browse/ARIES-27
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint
> Reporter: Andrew Osborne
> Assignee: Andrew Osborne
>
> Problem:
> The current beanProcessor is fairly restricted passing only the current Bean,
> and it's beanName, expecting the implementation to be able to do any
> 'processing' or substitution based only on that information.
> While this works well for simple bean wrappers, it's easy to see that some
> categories of BeanProcessor will struggle with such limited information.
> Eg, a processor may wish to dynamically replace the bean, to do so, it may
> require infomation from the original BeanMetadata. Additionally, a processor
> may need to return a wrapper, that when invoked obtains a bean dynamically.
> Proposal:
> Pass the bean metadata, and a 'BeanCreator' to the BeanProcessor, enabling
> the processor to instantiate a new Bean when required.
> This gets slightly more complex when there is more than one BeanProcessor
> operating, as each processor must still obtain a Bean that went through the
> same chain of Processors that it's orignal bean did.
> Eg. with 3 processors.
> A gets the fresh bean, and a BeanCreator for fresh beans
> B gets A's returned bean, and a BeanCreator that returns beans passed through
> A.
> C gets B's returned bean, and a BeanCreator that returns beans passed through
> A, then B.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
