"alesj" wrote : | Or why would you want to keep it as part of Controller? | I guess, I should answer this first. Initially, I tried to use BeanMetaData directly, but the problem I've been facing was that I found no means to retrieve the BeanMetaData directly, other than through the ContextController that was created through it. To me, we have 2 different problems that we have to solve: abstract beans and parent-child inheritance. They are different, because parent-child inheritance should be possible even if the parent is not abstract. Also, I considered the possibility that the parent and child are to be found in different deployments, even different scopes (with the parent being in the broader scope, obviously). Also, one needs to be consider that the parent can be undeployed or redeployed (what happens in this case? I would think that if we associate abstract beans with controller contexts, we could have dependencies and undeploy the child beans automatically). So, overall, the reason why I think this could be done this way is because I found out that the metadata management, as it is currently implemented, is based on the Controller/ControllerContext mechanism, once the BeanMetaData has been parsed and deployed by the Deployer all the references to it are held by ControllerContexts and managed via the Controller. This means that for getting the metadata for a particular bean, I have to go to the ControllerContext that has been created for that metadata. Of course, we can have better separation between metadata and the actual ControllerContext instances by introducing a registry holding the MetaData prior to deployment, but I think that this should also come at a price of a refactoring, to avoid duplicating features, such as scoping, for example, so I am not to sure how justified it is from the effort point of view. Of course, you know the MC much better inside out, so I'd like to know what your thoughts are about this. "alesj" wrote : | | I wouldn't put abstract definitions into Controller (under Described), | as I think they would do more harm than good on the overall impact. | | Do you have in mind anything specific or is this a general statement? Since there is a clear distinction between "DESCRIBED" and "INSTANTIATED" and "INSTALLED", I thought that it would be clear that the ControllerContext is not been backed by an actual instance, and this has the advantage that we can use all the existing mechanisms for management, scoping etc. But I'm interested to hear more on the topic. "alesj" wrote : | I would keep them in some nice, useful registry, | where I would also be able to define proper dependencies on them. | e.g. real bean deployed before its abstract parent, would mean dependency item on this abstract-registry | | This should be an impl detail of AbstractKernelController, | where the real abstract handling code would be separated. | | See above. If we were to have a definition registry, I think it should hold all the definitions (abstract and non-abstract) and it should be aware of scoping. But now that you're mentioning dependencies, I think it would be more natural to have child A depend on parent B in state DESCRIBED, rather than on a generic registry. With the former, child A cannot be installed until the abstract parent B is DESCRIBED, whereas if we had a single abstract-registry, that dependency would always be satisfied, even if the definition for the abstract bean hasn't been deployed yet, so I can't see what would be the use. Also, parent-child relationships can exist even between concrete beans, so if the registry is holding just abstract beans it would be of little use. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247445#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...