8:51 a.m.
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
}
}
@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
9:18 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
6:47 p.m.
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(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of
Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 12:18 AM
To: seam-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
12:25 a.m.
On 4/12/10 7:47 PM, 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?
Sounds great, but is there a way to hide this xml config from the
end-users and keep it within the module?
Stuart
________________________________________
From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of
Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 12:18 AM
To: seam-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
12:25 a.m.
yes, the xml would only need to go in the beans.xml of the module. When the end user wires
up a DroolsConfiguration in their beans.xml then the associated
KnowledgeBaseProducer,KnowledgeSessionProducer etc will get created automatically.
Stuart
________________________________________
From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 3:25 PM
To: Stuart Douglas
Cc: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Extending weld-extensions generic beans
On 4/12/10 7:47 PM, 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?
Sounds great, but is there a way to hide this xml config from the
end-users and keep it within the module?
Stuart
________________________________________
From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of
Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 12:18 AM
To: seam-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
1:15 a.m.
On 4/13/10 1:25 AM, Stuart Douglas wrote:
yes, the xml would only need to go in the beans.xml of the module.
When the end user wires up a DroolsConfiguration in their beans.xml then the associated
KnowledgeBaseProducer,KnowledgeSessionProducer etc will get created automatically.
Stuart
Cool! Let me know when I can test this out.
________________________________________
From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 3:25 PM
To: Stuart Douglas
Cc: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Extending weld-extensions generic beans
On 4/12/10 7:47 PM, 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?
>
>
Sounds great, but is there a way to hide this xml config from the
end-users and keep it within the module?
> Stuart
>
> ________________________________________
> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf
Of Tihomir Surdilovic [tsurdilo(a)redhat.com]
> Sent: Tuesday, 13 April 2010 12:18 AM
> To: seam-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
6:56 p.m.
I have implemented a preliminary version of this in seam-xml, the syntax is the same as
described in my original email.
The current problem that I am having is that I basically have to make an educated guess
where to install the additional qualifiers on the new bean. I think it needs to be changed
so this is explicitly specified in xml like so:
<genericBean class="org.jboss.seam.DroolsConfiguration">
<d:KnowledgeBaseProducer>
<specializes/>
<ApplyGenericQualifiers/>
<d:producerMethod><ApplyGenericQualifiers/></d:producerMethod>
</d:KnowledgeBaseProducer>
</genericBean>
and any qualifiers that have been placed on the configured DroolsConfiguration will be
applied wherever the <ApplyAnnotations> element is placed, which eliminated any
guesswork on my part, and also allows xml configuration of the bean to be installed.
Stuart
________________________________________
From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 4:15 PM
To: Stuart Douglas
Cc: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Extending weld-extensions generic beans
On 4/13/10 1:25 AM, Stuart Douglas wrote:
yes, the xml would only need to go in the beans.xml of the module.
When the end user wires up a DroolsConfiguration in their beans.xml then the associated
KnowledgeBaseProducer,KnowledgeSessionProducer etc will get created automatically.
Stuart
Cool! Let me know when I can test this out.
________________________________________
From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 3:25 PM
To: Stuart Douglas
Cc: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Extending weld-extensions generic beans
On 4/12/10 7:47 PM, 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?
>
>
Sounds great, but is there a way to hide this xml config from the
end-users and keep it within the module?
> Stuart
>
> ________________________________________
> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf
Of Tihomir Surdilovic [tsurdilo(a)redhat.com]
> Sent: Tuesday, 13 April 2010 12:18 AM
> To: seam-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
5:49 a.m.
This is now implemented with some minor changes. ApplyGenericQualifiers is now just
ApplyQualifiers, and qualifiers are automatically applied to the class without the need to
explicitly declare it. For example a framework writer puts the following in their modules
beans.xml:
<s:genericBean class="org.jboss.seam.DroolsConfiguration">
<d:KnowledgeBaseProducer>
<s:specializes/>
<d:producerMethod><s:ApplyQualifiers/></d:producerMethod>
</d:KnowledgeBaseProducer>
<d:KnowledgeSessionProducer>
<s:specializes/>
<d:producerMethod><s:ApplyQualifiers/></d:producerMethod>
</d:KnowledgeSessionProducer>
</s:genericBean>
The end user then wires up two DroolsConfigurations objects in their app's beans.xml:
<d:DroolsConfiguration>
<my:SecurityRules/>
<d:ruleBase>/path/to/sec/rules<d:ruleBase>
</d:DroolsConfiguration/>
<d:DroolsConfiguration>
<my:BuisinessRules/>
<d:ruleBase>/path/to/bus/rules<d:ruleBase>
</d:DroolsConfiguration/>
For each DroolsConfiguration the user creates a corresponding KnowledgeBaseProducer and
KnowledgeSessionProducer are created with the same qualifier (i.e. @SecurityRules and
@BuisinessRules). In addition the qualifiers are applied anywhere the
<ApplyQualifiers> element appears, in this case on the producer methods so the
produced objects will have the same Qualifiers as the DroolsConfiguration.
This feature is aimed more at framework writers than at the end user. If anyone has any
suggestions / comments please let me know.
Stuart
On 14/04/2010, at 9:56 AM, Stuart Douglas wrote:
I have implemented a preliminary version of this in seam-xml, the syntax is the same as
described in my original email.
The current problem that I am having is that I basically have to make an educated guess
where to install the additional qualifiers on the new bean. I think it needs to be changed
so this is explicitly specified in xml like so:
<genericBean class="org.jboss.seam.DroolsConfiguration">
<d:KnowledgeBaseProducer>
<specializes/>
<ApplyGenericQualifiers/>
<d:producerMethod><ApplyGenericQualifiers/></d:producerMethod>
</d:KnowledgeBaseProducer>
</genericBean>
and any qualifiers that have been placed on the configured DroolsConfiguration will be
applied wherever the <ApplyAnnotations> element is placed, which eliminated any
guesswork on my part, and also allows xml configuration of the bean to be installed.
Stuart
________________________________________
From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
Sent: Tuesday, 13 April 2010 4:15 PM
To: Stuart Douglas
Cc: seam-dev(a)lists.jboss.org
Subject: Re: [seam-dev] Extending weld-extensions generic beans
On 4/13/10 1:25 AM, Stuart Douglas wrote:
> yes, the xml would only need to go in the beans.xml of the module. When the end user
wires up a DroolsConfiguration in their beans.xml then the associated
KnowledgeBaseProducer,KnowledgeSessionProducer etc will get created automatically.
>
> Stuart
>
>
Cool! Let me know when I can test this out.
> ________________________________________
> From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
> Sent: Tuesday, 13 April 2010 3:25 PM
> To: Stuart Douglas
> Cc: seam-dev(a)lists.jboss.org
> Subject: Re: [seam-dev] Extending weld-extensions generic beans
>
> On 4/12/10 7:47 PM, 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?
>>
>>
> Sounds great, but is there a way to hide this xml config from the
> end-users and keep it within the module?
>
>> Stuart
>>
>> ________________________________________
>> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On
Behalf Of Tihomir Surdilovic [tsurdilo(a)redhat.com]
>> Sent: Tuesday, 13 April 2010 12:18 AM
>> To: seam-dev(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>>
>>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
8:14 a.m.
Looks really nice at first glance.
On 14 Apr 2010, at 11:49, Stuart Douglas wrote:
This is now implemented with some minor changes. ApplyGenericQualifiers is now just
ApplyQualifiers, and qualifiers are automatically applied to the class without the need to
explicitly declare it. For example a framework writer puts the following in their modules
beans.xml:
<s:genericBean class="org.jboss.seam.DroolsConfiguration">
<d:KnowledgeBaseProducer>
<s:specializes/>
<d:producerMethod><s:ApplyQualifiers/></d:producerMethod>
</d:KnowledgeBaseProducer>
<d:KnowledgeSessionProducer>
<s:specializes/>
<d:producerMethod><s:ApplyQualifiers/></d:producerMethod>
</d:KnowledgeSessionProducer>
</s:genericBean>
The end user then wires up two DroolsConfigurations objects in their app's
beans.xml:
<d:DroolsConfiguration>
<my:SecurityRules/>
<d:ruleBase>/path/to/sec/rules<d:ruleBase>
</d:DroolsConfiguration/>
<d:DroolsConfiguration>
<my:BuisinessRules/>
<d:ruleBase>/path/to/bus/rules<d:ruleBase>
</d:DroolsConfiguration/>
For each DroolsConfiguration the user creates a corresponding KnowledgeBaseProducer and
KnowledgeSessionProducer are created with the same qualifier (i.e. @SecurityRules and
@BuisinessRules). In addition the qualifiers are applied anywhere the
<ApplyQualifiers> element appears, in this case on the producer methods so the
produced objects will have the same Qualifiers as the DroolsConfiguration.
This feature is aimed more at framework writers than at the end user. If anyone has any
suggestions / comments please let me know.
Stuart
On 14/04/2010, at 9:56 AM, Stuart Douglas wrote:
>
> I have implemented a preliminary version of this in seam-xml, the syntax is the same
as described in my original email.
>
> The current problem that I am having is that I basically have to make an educated
guess where to install the additional qualifiers on the new bean. I think it needs to be
changed so this is explicitly specified in xml like so:
>
> <genericBean class="org.jboss.seam.DroolsConfiguration">
> <d:KnowledgeBaseProducer>
> <specializes/>
> <ApplyGenericQualifiers/>
> <d:producerMethod><ApplyGenericQualifiers/></d:producerMethod>
> </d:KnowledgeBaseProducer>
> </genericBean>
>
> and any qualifiers that have been placed on the configured DroolsConfiguration will
be applied wherever the <ApplyAnnotations> element is placed, which eliminated any
guesswork on my part, and also allows xml configuration of the bean to be installed.
>
> Stuart
>
>
> ________________________________________
> From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
> Sent: Tuesday, 13 April 2010 4:15 PM
> To: Stuart Douglas
> Cc: seam-dev(a)lists.jboss.org
> Subject: Re: [seam-dev] Extending weld-extensions generic beans
>
> On 4/13/10 1:25 AM, Stuart Douglas wrote:
>> yes, the xml would only need to go in the beans.xml of the module. When the end
user wires up a DroolsConfiguration in their beans.xml then the associated
KnowledgeBaseProducer,KnowledgeSessionProducer etc will get created automatically.
>>
>> Stuart
>>
>>
> Cool! Let me know when I can test this out.
>> ________________________________________
>> From: Tihomir Surdilovic [tsurdilo(a)redhat.com]
>> Sent: Tuesday, 13 April 2010 3:25 PM
>> To: Stuart Douglas
>> Cc: seam-dev(a)lists.jboss.org
>> Subject: Re: [seam-dev] Extending weld-extensions generic beans
>>
>> On 4/12/10 7:47 PM, 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?
>>>
>>>
>> Sounds great, but is there a way to hide this xml config from the
>> end-users and keep it within the module?
>>
>>> Stuart
>>>
>>> ________________________________________
>>> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On
Behalf Of Tihomir Surdilovic [tsurdilo(a)redhat.com]
>>> Sent: Tuesday, 13 April 2010 12:18 AM
>>> To: seam-dev(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
9:22 a.m.
Something like this would be great for the JMS project as I have a similar
issue when trying to inject MessageProducer/MessageConsumers that depend on
specific destinations.
On Mon, Apr 12, 2010 at 9:51 AM, Stuart Douglas <stuart(a)baileyroberts.com.au
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
}
}
@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Jordan Ganoff
5366
days inactive
5368
days old
9 comments
4 participants
participants (4)
-
Jordan Ganoff -
Pete Muir -
Stuart Douglas -
Tihomir Surdilovic