[webbeans-dev] BeanImpl/BeanModel/AnnotatedItem split

[Pete Muir]

Oh, and yes, this should be named better, but I got stuck...

On 13 Nov 2008, at 20:12, Pete Muir 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
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev