[jboss-as7-dev] EJB subsystem refactoring

[Carlo de Wolf]

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?
>>
>>
>> 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.

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