On Monday 22 August 2011 08:42 AM, Stuart Douglas wrote: > 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 Yes, I would like that one to go too. I had removed a few usages to that, when we ran into the issues that you mention, but there are some more DUPs which are still using it.

> > > This approach has a number of advantages: > > ... > - 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. > Is this specific to just EJB3? Because we need similar construct for other parts too (whichever component requires annotation, deployment descriptor and merging). > > 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: > When we started with refactoring EE some time back, I remember David had mentioned a reason why he didn't want the ComponentConfiguration to be sub-classed. I no longer remember what that reason was. But yeah, you are right that at present, we end up pushing such data to the (sub-classed) component create service and pass it on to the component.

> Does all this sound reasonable? > > Overall, I don't have any objection to these changes. -Jaikiran

On 22/08/2011, at 6:11 PM, Carlo de Wolf wrote: > On 08/22/2011 08:40 AM, Jaikiran Pai wrote: >> On Monday 22 August 2011 08:42 AM, Stuart Douglas wrote: >>> 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 >> Yes, I would like that one to go too. I had removed a few usages to that, when we ran into the issues that you mention, but there are some more DUPs which are still using it. > +1 > > It needs to be replaced by something that mimics the way we operate. It was an outgrowth of duplicate code that popped up in the DUPs. > > First and foremost we need to decide whether the DUPs are going to be target metadata driven. Or do we still want to separate different stages like annotation processing, parsing, merging etc? In my prototype I have a two phase process, first the annotations are read into the shared EEModuleClassDescription, and then later they are merged with the DD data into the description. >>> >>> This approach has a number of advantages: >>> >>> ... >>> - 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. >>> >> Is this specific to just EJB3? Because we need similar construct for other parts too (whichever component requires annotation, deployment descriptor and merging). >>> 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: >>> >> When we started with refactoring EE some time back, I remember David had mentioned a reason why he didn't want the ComponentConfiguration to be sub-classed. I no longer remember what that reason was. But yeah, you are right that at present, we end up pushing such data to the (sub-classed) component create service and pass it on to the component. > I designed the effigy API specifically for a post-classloader metadata store. So why not use it? > > In fact we had some code in the past where parts of the component description/configuration acted as effigy facades. > > Most importantly you want to separate the runtime from any of the description/configuration hacks. I'm not really sure what the Effigy API can do for us here, it looks like it is not really a good fit for the current description / configuration approach. Stuart

> Carlo >>> Does all this sound reasonable? >>> >>> >> Overall, I don't have any objection to these changes. >> >> -Jaikiran >>