[jboss-dev-forums] [Design the new POJO MicroContainer] - JBMICROCONT-309; aliases and scoping

With Kabir's issue: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154037#... I've re-factored scoped kernel/controller code a bit. The new addition makes aliases pretty useful now. :-) The detail is in the state they are added - past PRE_INSTALL (after scoping). It solves what we mostly want to do with an alias and scoped beans. But the problem we're inconsistent with how we do the aliases - scoping aliases to be exact. Focusing just on scoping + alias: In my new code, where I handle aliases on annotation, my controller is already scoped, so my alias is unique in that controller scope. This makes combination of global unique bean name + scoped alias a great asset for other scoped beans (Kabir's issue use case) - but see issue1. Issue#1: Controller should have option to do just local lookup - otherwise order of bean deployment is important; e.g. picking up bean from parent (already available), where you would actually want scoped one (not available at dependency item resolution) This can also lead to CCE issues; parent bean being of wrong type Currently scoping controllers are completely transparent, visible only to top level controller. And as such, install and uninstall only take place at the top, propagating the action to the right controller based on the (hopefully) unique name. Issue#2: If we do alias addition after scoping (post PreInstall), the alias (context) name is unique, since it's signed by controller id (new notion I needed to add). But currently we register context's aliases in Controller:install, which is way too early. :-) Hence we loose alias (context) name uniqueness - they are all signed by top controller. Alias addition should be done in Describe state, since I very much doubt anybody depends on the bean via alias before Describe state. This would solve the uniqueness problem. Aliases can also be deployed separately - see DeploymentAliasDeployer in deployers project. Issue#3: NamedAliasMetaData is missing a way to specify to which scope this alias should be installed. In order to do this, there are two ways that I see: 1) Controller::add/removeAlias take ScopeKey parameter, NamedAliasMetaData knows how to create that scope key 2) NamedAliasMetaData takes annotations, AliasControllerContext uses MetaData to keep that annotations, and we use the same lookup mechanism as we do in PreInstallAction With all this, once we abandon context name notion - making it automatically unique - defining aliases and coding against them would make scoping truly usable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161684#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...