&quot;adrian(a)jboss.org&quot; wrote : &quot;kabir.khan(a)jboss.com&quot; wrote : | | So it would seem that when creating the properties for the bean, it uses the MetaData for the bean, which does not contain the methods for the properties. Maybe we need to call MetaDataStack.mask() as part of ConfigureAction.setAttributes()? | | | | Is that the cause or are you guessing? | | Do you know where the wrong ConstructorInfo is coming from. I believe it is the cause, but I am not so familiar with that part of MC. Let's call it an educated guess :-) Looking at EndpointRecordProcessorDeploymentAspect, it does contain a List property called "processors". Setting a breakpoint again, different class this time, it fails for a bean of type org.jboss.ejb3.cache.CacheFactoryRegistry. This contains a property | public class CacheFactoryRegistry | { | // Instance Members | private Map<String, Class<? extends Ejb3CacheFactory>> factories; | | // Accessors / Mutators | | public Map<String, Class<? extends Ejb3CacheFactory>> getFactories() | { | return factories; | } | | public void setFactories(Map<String, Class<? extends Ejb3CacheFactory>> factories) | { | this.factories = factories; | } | ... | } | The stack trace this time is | AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(Signature) line: 150 | AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) line: 276 | MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) line: 160 | AOPConstructorJoinpoint.methodHasSubInstanceMetaData(MetaData, MethodInfo) line: 171 | AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(MetaData) line: 149 | AOPConstructorJoinpoint.rootHasSubInstanceMetaData(MetaData) line: 129 | AOPConstructorJoinpoint.dispatch() line: 92 | AbstractMapMetaData(AbstractTypeMetaData).createInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 251 | AbstractMapMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 292 | AbstractMapMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>) line: 271 | AbstractMapMetaData.getValue(TypeInfo, ClassLoader) line: 117 | PropertyDispatchWrapper.execute() line: 87 | PropertyDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47 | KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109 | ConfigureAction.dispatchSetProperty(KernelControllerContext, PropertyMetaData, boolean, BeanInfo, Object, ClassLoader) line: 109 | ConfigureAction.setAttributes(KernelControllerContext, Object, BeanInfo, BeanMetaData, boolean) line: 87 | ConfigureAction.installActionInternal(KernelControllerContext) line: 44 | ConfigureAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54 | ConfigureAction(InstallsAwareAction).installAction(ControllerContext) line: 42 | ConfigureAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62 | ConfigureAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71 | KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51 | AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 | The KCC in AbstractKernelControllerContext has the name EJB3CacheFactoryRegistry, and it is of type org.jboss.ejb3.cache.CacheFactoryRegistry. Looking at ConfigureAction.setAttributes() it iterates over the properties, and is currently on | AbstractPropertyMetaData@f4561{name=factories value=AbstractMapMetaData@4b5a7b{value=null type=java.util.HashMap}} | This then calls dispatchSetProperty() which ends up in AOPConstructorJoinPoint(0 to create the HashMap value to be configured. So it is not a "wrong" ConstructorInfo, the CacheFactoryRegistry was already created properly. It happens when creating the properties. Convinced? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166375#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...