Much like the ValidatorChain I've just introduced (JBMETA-118), we need to allow for a chain of post-processors upon metadata to arbitrarily muck around. I've got two use cases: 1) @LocalBinding.jndiBinding value should be set to JBossSessionBeanMetaData.localJndiName. Currently this is done directly in LocalBindingProcessor, but this bypasses a LocalBindingMetaData object view entirely (JBMETA-119). A better solution would be for LocalBindingProcessor to create the full object model, and have the local jndi name set to the proper value as a post-processing task. 2) "EJB3 Core Spec 4.6.6" wrote : If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the | interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor. The current implementation has a problem: the first pass is done on annotation-based metadata, which will default the local business interface if none is explicitly marked. However, it may be XML that's marking as @Remote, in which case we end up with both a local and remote business interface of the same type, which is a violation of spec: "EJB3 Core Spec 4.6.6" wrote : The same business interface cannot be both a local and a remote business interface of the bean. So I'm going to look into adding a PostProcessingChain to run on fully parsed and merged metadata, much like ValidatorChain does now. I'm thinking also that Validation is a specific type of processing, and that the two might be combined for simplicity's sake. I'll head that route if I can get the APIs to remain friendly for both purposes. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182064#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...