[webbeans-dev] BeanImpl/BeanModel/AnnotatedItem split
Gavin King
gavin at hibernate.org
Sun Nov 9 09:50:55 EST 2008
We now have 20 fewer tests?
On Sun, Nov 9, 2008 at 3:01 AM, Pete Muir <pmuir at redhat.com> wrote:
> 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
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
--
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
More information about the weld-dev
mailing list