[weld-dev] [seam-dev] Extending weld-extensions generic beans

[Pete Muir]

[move to weld-dev as this has become a spec discussion]

Speaking to Stuart on IRC, he summarised it for me as:

"What I wanted to do was look for an annotation on a class @Generic(DroolsConfiguration.class), and then for every DroolsConfiguration that gets installed install a new one of that class with the same qualifiers but by the time I know about the class, it is to late, and I would need to use AfterBeanDiscovery.addBean. I think there are more use cases as well, basically anything that wants to add beans based on what it finds in the deployment and it is much easier to do it with addAnnotatedType than addBean"

I think this can be easily solved by making the initialisation lifecycle a bit more granular:

1) Fire BeforeBeanDiscovery [*] , firing ProcessAnnotatedType for each type added via ProcessAnnotatedType
2) Discover all AnnotatedTypes from bean archives, firing ProcessAnnotatedType for each type discovered
3) Fire AfterTypeDiscovery <<< Inserted step, firing ProcessAnnotatedType for each type added via ProcessAnnotatedType
4) Fire ProcessBean for each Bean created
5) Fire AfterBeanDiscovery

[*] Possibly you would want to rename BeforeBeanDiscovery to BeforeTypeDiscovery in an ideal world?

Is it possible to get this into the MR?


On 13 Apr 2010, at 00:47, Stuart Douglas wrote:

> So this is going to be much harder to implement than I thought. Because I want to look at the types that come through ProcessAnnotatedType I need to install the generic beans using AfterBeanDiscovery.addBean. This is much harder to use for this purpose than BeforeBeanDiscovery.addAnnotatedType, and no matter what I do there will be subtle and not so subtle differences between these beans and 'native' weld bean (e.g. interceptors and decorators won't work). 
> 
> Ideally it would also be possible to do AfterBeanDiscovery.addAnnotatedType, however for the moment the only real solution that I can see is to put this functionality in the XML module, and require the extension developer to explicitly declare their generic beans in XML. This way all the information is available in BeforeBeanDiscovery, and I can add the generic beans using addAnnotatedType. 
> 
> I think the syntax would be something like this:
> 
> <genericBean class="org.jboss.seam.DroolsConfiguration">
>   <d:KnowledgeBaseProducer/>
>   <d:KnowledgeSessionProducer/>
> </genericBean>
> 
> Does this sound like a reasonable solution?
> 
> Stuart
> 
> ________________________________________
> From: seam-dev-bounces at lists.jboss.org [seam-dev-bounces at lists.jboss.org] On Behalf Of Tihomir Surdilovic [tsurdilo at redhat.com]
> Sent: Tuesday, 13 April 2010 12:18 AM
> To: seam-dev at lists.jboss.org
> Subject: Re: [seam-dev] Extending weld-extensions generic beans
> 
> On 4/12/10 9:51 AM, Stuart Douglas wrote:
>> After talking with Tihomir over the last few days about the seam-drools module I think that there is base functionality that is missing that belongs in weld-extensions as it is similar to the existing generic bean code.
>> 
>> I will use an example from the drools module to outline the problem:
>> 
>> The drools module has a DroolsConfiguration object that contains configuration, this can be installed via XML and there can be multiple DroolsConfigrations per app. for every DroolsConfiguration several object need to be produced e.g. KnowledgeBase, StatefullKnowledgeSession and a KnowledgeRuntimeLogger.
>> 
>> currently we would need to do something like this:
>> 
>> <  d:DroolsConfiguration>
>>   <app:SomeQualifier>
>>   ...configuration
>> </d:DroolsConfiguration>
>> 
>> 
>> <d:KnowlegdeBaseProducer>
>>   <d:producerMethod>
>>     <app:SomeQualifier>
>>     <s:parameters>
>>       <d:DroolsConfiguration>
>>        <s:Inject/>
>>        <app:SomeQualifier/>
>>      </d:DroolsConfiguration>
>>     </s:parameters>
>>   </d:producerMethod>
>> </d:KnowlegdeBaseProducer>
>> 
>> ...same for StatefullKnowledgeSession, StatelessKnowledgeSession, KnowledgeRuntimeLogger etc.
>> 
>> and wire up a producer like that for every object being created from the DroolsConfiguration. This is not good. The user should be able to just wire up the configuration and the rest of the beans should be created automatically. I think we should be able to do something like this:
>> 
>> @Generic(DroolsConfiguration.class)
>> class KnowledgeBaseProducer
>> {
>>   @Produces
>>   @GenericQualifiers
>>   public KnowledgeBase producerMethod(@Inject @GenericQualifiers DroolsConfiguration config )
>>   {
>>    //do stuff
>>   }
>> 
> and also disposer methods with for example:
> void disposerMethod(@Disposes @GenericQualifiers KnowledgeBase kbase)
> {
> ...
> }
> 
> Thanks!
>> }
>> 
>> @Generic tell the extensions to register a new KnowledgeBaseProducer bean for every DroolsConfiguration found.
>> @GenericQualifiers is replaced with the qualifiers on the DroolsConfiguration object when the bean is added.
>> 
>> This means that all an end user has to do is wire up a single DroolsConfiguration object and everything just works.
>> 
>> Does this sound like a good idea? Is there anything I have overlooked?
>> 
>> Stuart
>> 
>> 
>> 
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>> 
>> 
> 
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
> 
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev