[webbeans-dev] BeanImpl/BeanModel/AnnotatedItem split

[Pete Muir]

Ok, I just committed the first round of this:

* Merge *Model into *Bean, all init* and check* methods should be put  
there
* I created an EventBean from EventModel, but I don't quite understand  
the architecture of the Event stuff so, David, I may have broken stuff  
here
* I removed all the *Constructor stuff
* I removed the xmlAnnotatedItem stuff, and put in an example of how  
we could do this with XmlSimpleBean, and adding the common logic  
higher up the class hierarchy, for example

protected void initType() {
    if (isDefinedInXml()) {
       // Do XML init from parsed XML data structure
    } else {
       // Do init from reflection
    }
}

I would like someone to review this architecture (Gavin ;-)...

* Gavin, I tried not to clobber your commits around lifecycle  
callbacks and EJB lookup when merging this in. The tests do pass, so  
if they covered all cases, then it should be good :-)

Next, I plan to merge the behaviour of fields (inject value from  
manager), parameters (inject from manager) and methods (invoke,  
injecting parameters from manager) into the reflection layer. I'll  
also tidy up usage of this layer across the whole codebase, and add  
some javadoc. I'll try to commit this on Thursday.

Pete

On 6 Nov 2008, at 18:43, Pete Muir wrote:

> Continuing with my monologue, once we merge the model into BeanImpl,  
> I also want to review the Injectable stuff, I don't think that is  
> quite right, it should probably merged into the the annotated* stuff  
> or merged into BeanImpl.
>
> I want to do producer methods first, then consider this, as at that  
> point I will have a much clearer picture of what is sensible (that  
> was the "motivation" for this - I didn't know where I was going well  
> enough back in June).
>
> WDYT?
>
> On 6 Nov 2008, at 10:53, Pete Muir wrote:
>
>> But I still think the abstraction over reflection is useful  
>> (annotated*) not least because it encapsulates all the logic re.  
>> meta-annotations and fixes the class hierarchy.
>>
>> On 6 Nov 2008, at 10:41, Pete Muir wrote:
>>
>>> I agree, it's on my todo list (to merge model and BeanImpl) to one.
>>>
>>> On 6 Nov 2008, at 06:33, Gavin King wrote:
>>>
>>>> Pete,
>>>>
>>>> would you be able to explain what is motivating the use of a
>>>> "3-layered" approach to the Bean implementations?
>>>>
>>>> I'm finding the resulting parallel class hierarchies really  
>>>> difficult
>>>> to work with. In particular, I got totally stuck on the  
>>>> implementation
>>>> of MethodConstructor.invoke() for producer methods.
>>>>
>>>> I really think the code would end up a lot more elegant if we
>>>> flattened stuff out into the Bean subclasses...
>>>>
>>>> -- 
>>>> Gavin King
>>>> gavin.king at gmail.com
>>>> http://in.relation.to/Bloggers/Gavin
>>>> http://hibernate.org
>>>> http://seamframework.org
>>>> _______________________________________________
>>>> webbeans-dev mailing list
>>>> webbeans-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>
>>> _______________________________________________
>>> webbeans-dev mailing list
>>> webbeans-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev