[jboss-as7-dev] EJB subsystem refactoring

Stuart Douglas stuart.w.douglas at gmail.com
Sun Aug 21 23:12:36 EDT 2011


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...stuartwdouglas:ee-reorg

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/jboss/as/ejb3/component/session/SessionBeanComponentDescription.java#L132

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/jboss/as/ejb3/component/EJBComponentCreateService.java#L86

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/jboss/as/ejb3/component/singleton/SingletonComponent.java#L66
https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/singleton/SingletonComponent.java#L151

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20110822/bebdd0fe/attachment.html 


More information about the jboss-as7-dev mailing list