[webbeans-dev] BeanImpl/BeanModel/AnnotatedItem split

[Gavin King]

Great!

On Thu, Nov 13, 2008 at 5:12 AM, Pete Muir <pmuir at redhat.com> wrote:
> I've now done the second phase of this.
>
> Pretty much everything is now done through the Annotated* which is a wrapper
> around Java Reflections which adds:
>
> * Annotation support for elements of classes
>
>   List<AnnotatedConstructor> constructorsAnnotatedWithInitializer =
> clazz.getAnnotatedConstructors(Initializer.class);
>
> * Meta annotation support for elements of classes
>
>   List<AnnotatedField> fieldsWithBindingTypesOnThem =
> clazz.getMetaAnnotatedFields(BindingType.class);
>
> * injection aware invocations
>
>   AnnotatedClass<Foo> = new AnnotatedClassImpl(Foo.class);
>   Foo instance =
> clazz.getAnnotatedConstructors(Initializer.class).iterator().next().newInstance(manager);
>
> would create a new instance of the first constructor annotated @Initializer,
> injecting all parameters
>
> Alternatively, you could do:
>
> field.inject(manager); to inject a field
>
> * Make Parameter a first class construct
>
> e.g.
>
> paramter.getAnnotations();
> parameter.getValue(manager);
> parameter.getType()
> parameter.isStatic();
>
> * Even out the Modifiers into javabean methods
>
> clazz.isStatic();
> clazz.isFinal();
>
> I've been building this as we go along, so the layer is not complete. It can
> be added to as needed...
>
>
> On 9 Nov 2008, at 18:01, Pete Muir 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