[jboss-as7-dev] EJB subsystem refactoring

Hi everyone, There is some fairly major refactoring I would like to do ti the EJB/EE subsystem, I just thought I would run it by everyone to see if anyone had any suggestions / objections. 1) Remove AbstractAnnotationEJBProcessor, and replace it with a system that attaches annotation information directly to EEModuleClassDescription I have a prototype of this at: https://github.com/stuartwdouglas/jboss-as/compare/jbossas:master...stuar... This approach has a number of advantages: - AbstractAnnotationEJBProcessor does not handle annotations in different sub deployments properly, so if a bean inherits from classes in another sub deployment those annotations will not be processed (this has potential security implications for things like the EJB security annotations). - This should remove a lot of boilerplate code that is present in the annotation processors (I know at the moment the patch increases the total loc slightly, but after all the processors are converted it should reduce it) - It should give us a more consistent approach to merging, at the moment there is a deployment descriptor processor, and annotation processor, and a merging processor, that are mostly copied / pasted all over the place. With this change there will only by 1 processor, that is responsible for merging the annotation and descriptor data, and attaching it to the description/configuration. 2) Subclass ComponentConfiguration for each component type At the moment there is no where to store post class loading metadata for EJB components. This has been worked around with nasty hacks, either by storing post-class loading stuff in the description: https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jb... Or by performing configuration work in the ComponentCreateService that should really be done in DUP's / configurators: https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jb... In some cases this has resulted in EjbComponent's using maps keyed on MethodIdentifier internally, rather than a faster IdentityMap with the actual method objects from the reflection index. https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jb... https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jb... There are also places in the code where we go from a Method object, store a MethodIdentifer, and then later re-resolve the original Method object, which is not ideal. Does all this sound reasonable? Stuart