"adrian(a)jboss.org" wrote : | It's deliberately "not as integrated as it could be". | Because I want you to be able to write your own BeanMetaDataFactory | to do whatever you like, e.g. see the VFSClassLoaderFactory in the new classloaders. | | If you can't write your own then theres something wrong with the rest of the api. ;-) | | The beanfactory/GenericBeanMetaDataFactory is just an example that happens | to live in the MC codebase and xml namespace. :-) Yes, but we are talking about different apis. The BeanFactory which creates instances and BeanMetaDataFactory which provides collections of BeanMetaData. Maybe BeanFactory is no longer preferred and the beanfactoryType description in bean-deployer_2_0.xsd referring to GenericBeanFactory is out of date. I see the GenericBeanMetaDataFactory is annotated as the beanfactoryType as well. It seems both notions are needed, a BeanMetaDataFactory describes a collection of interrelated beans, the BeanFactory controls how instances are obtained. A javaee container has a BeanMetaDataFactory for its container/aspects, and a BeanFactory for obtaining instances. Back to my other question about the benefit of a beanfactory (as in BeanFactory) vs a ctor factory, its a semantic difference only from the point of view of who is actually creating bean instances. The mc deployer InstantiateAction has a one instance to one BeanMetaData view. I need a container notion where the state machine dependencies represented by the BeanMetaData collections end up injecting an instance that is a function of the "key" type for the bean and pooling policy. I guess this can be encapsulated in the injection value metadata, but its a bit abstract still. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138101#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...