You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Jeremy Hughes (JIRA)" <ji...@apache.org> on 2010/02/24 17:44:37 UTC

[jira] Updated: (ARIES-46) Invoke namespace handler for custom scope elements.

     [ https://issues.apache.org/jira/browse/ARIES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Hughes updated ARIES-46:
-------------------------------

    Fix Version/s: 0.1

> Invoke namespace handler for custom scope elements. 
> ----------------------------------------------------
>
>                 Key: ARIES-46
>                 URL: https://issues.apache.org/jira/browse/ARIES-46
>             Project: Aries
>          Issue Type: New Feature
>          Components: Blueprint
>            Reporter: Andrew Osborne
>            Assignee: Andrew Osborne
>             Fix For: 0.1
>
>
> Update the parser to further process the scope attribute for bean definitions, and to invoke a namespace handler for the scopes value.
> If the scope is a custom scope, the appropriate namespace handler will be invoked, passing the Attr Node representing the scope attribute from the blueprint definition. 
> Intent is to use the presence of ':' within the scope value to determine if the value is a custom scope or not. If the ':' is present, to split on the : resolve the namespace prefix part as per the current element, and use the resulting namespace to check for and invoke the NamespaceHandler. If no handler is registered, the parse is aborted just as if any other non-handled element is encountered. 
> Once invoked an Namespace Handler can then inject a bean processor to handle it's implementation, or whatever else it wants to do in reaction to seeing the custom scope. 
> I like the idea of extending BeanProcessor to create ScopedBeanProcessors that will only be invoked if the bean being processed is associated to the scope of the processor, but think this could be done in a seperate issue.
> The logic up in AbstractRecipe will likely need a cleanup, as it heavily makes the assumption that only singleton/prototype are possible, and is phrased today to check for singleton by testing for "not prototype". Will need to resolve if custom scopes should act as singleton/prototype wrt addFull / addPartial object, or if this should be configurable. This can also be resolved in a seperate issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.