You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2012/03/04 16:52:27 UTC
[DISCUSS] DELTASPIKE-14 GenericBeans
Hi All
I would like to begin discussing the use of Generic Beans from Solder
(currently this issue is assigned to Antoine, but I have some bandwidth and
offered to help him here). This feature is used to configure a set of
related beans that require shared components, while still allowing scopes
to be provided. This is useful when trying to make legacy libraries/APIs
CDI capable. The following are the API components required for
GenericBeans:
- @GenericType(Class<?> clazz) - defines the type of configuration for the
generic. This annotation is placed on another annotation, as defined by
the application developer or framework author to support how configuration
is resolved. This will look for a matching bean of the given type and
resolve it based on the annotation that this is assigned to.
- @Generic - when using the manager type, defines an expected injection
point for a generic bean.
- @GenericConfiguration(Class<?> clazz) - defines the relationship between
generic objects.
- @ApplyScope - indicates that the produced object should inherit the scope
of the configuration.
The examples in the Solder documentation describe this in depth:
http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
Thoughts/questions on the feature?
john
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
Gerhard,
I understand use case are a bit complex to explain. I'm preparing a university talk on Seam social for Devoxx France on april 18th. I'll use this talk material to write a post on Genercis during easter holiday. So we'll have a clearly explained use case on the subject.
Antoine SABOT-DURAND
Le 30 mars 2012 à 17:28, Gerhard Petracek a écrit :
> @antoine:
> i know - i was talking about using std. cdi mechanisms without introducing
> a whole new approach in between.
> however, for sure i'm ok with discussing this feature. we can have a look
> at the current usage and possible alternatives.
>
> maybe it's easier to start with the usage in infinispan.
> @pete: it would be great, if you can describe the details.
>
> regards,
> gerhard
>
>
>
> 2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
>
>> Gerahrd,
>>
>> I understand what you. Generic Beans are based on standard CDI as all
>> extension we are doing in DS. Before using them I had a lot of extension
>> to deal with my need. Generic Beans in seam social makes dev save about 50
>> lines of oct for each OAuth Application declared(should it be only one for
>> each SN, it's already more than 50). It's a great helper. I'm not sure of
>> how the feature is used in Infinispan but it looks like the same need.
>>
>> CDI is strong typed and it's good but having a smart extension that can
>> produce a bunch of bean with different scope and unknown qualifiers at
>> compile time brings a dynamic aspect without forgetting the strong typed
>> aspect.
>>
>> I'd be pleased if you have a look at Seam social[1] and see how they are
>> used. So you could take half time to tell me how to do without them (but I
>> already now, since I did without them before) and half time to see the
>> potential of Generics.
>>
>> regards
>>
>>
>> Antoine
>> [1] http://github.com/seam/social
>>
>>
>> Le 30 mars 2012 à 14:01, Pete Muir a écrit :
>>
>>> Hi Gerhard,
>>>
>>> Do you have some examples of configuring a "family of beans" in MyFaces
>> CODI, where the family can be easily reused for different, coexisting,
>> services? This would be very helpful so that we can see how CODI achieved
>> this.
>>>
>>> pete
>>>
>>> On 30 Mar 2012, at 12:53, Gerhard Petracek wrote:
>>>
>>>> hi antoine,
>>>>
>>>> a lot of parts of myfaces codi are also customizable (easily) and almost
>>>> all of them are based on std. cdi mechanisms.
>>>>
>>>> if the social module has special requirements, we can discuss the
>>>> alternatives.
>>>> if a std. based approach requires just a bit more effort to support new
>>>> social services, it's ok imo because you don't have to do it that often.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>
>>>>> So what's next on "Bean Familiy Producer" ?
>>>>>
>>>>> They are used in infinispan cdi [1] and Seam Social [2].
>>>>> In both case they are used to provide pug ability with unknown
>>>>> implementation (I Can create a new Cache module with a new technology
>> or I
>>>>> can create a new Social Network Module for the last Twitter in town)
>>>>>
>>>>> So we agree it's mainly a framework development need to avoid users to
>>>>> have to create a bunch of producers when they extend the framework.
>>>>>
>>>>> As it's used to produce beans they can be in different scope or merit
>>>>> dynamically of master bean scope.
>>>>>
>>>>> To make it short : it seems rather useful even if the use cases are
>> narrow.
>>>>>
>>>>> Does anybody have questions, objections ? Should we go for a vote ?
>>>>>
>>>>>
>>>>> [1]
>>>>>
>> https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
>>>>> [2]
>>>>>
>> https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
>>>>>
>>>>> Antoine SABOT-DURAND
>>>>>
>>>>>
>>>>>
>>>>> Le 9 mars 2012 à 17:32, Pete Muir a écrit :
>>>>>
>>>>>> I quite like Bean Family Producer actually.
>>>>>>
>>>>>> On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
>>>>>>
>>>>>>> What about "Bean Family" or "Bean Family Producer" ?
>>>>>>>
>>>>>>>
>>>>>>> Antoine SABOT-DURAND
>>>>>>>
>>>>>>>
>>>>>>> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
>>>>>>>
>>>>>>>> Yes, we need a new name for the feature, generic beans isn't good
>> ;-)
>>>>>>>>
>>>>>>>> I'm not sure Bean Groups is right, any other ideas?
>>>>>>>>
>>>>>>>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>>>>>>>>
>>>>>>>>> @pete
>>>>>>>>>
>>>>>>>>> Reminds me of the JMS issue we have.
>>>>>>>>>
>>>>>>>>> So I suppose - could we rename the feature - "Bean Groups" ? Then
>>>>> describe
>>>>>>>>> the feature more along the lines of "the ability to define a bean
>> that
>>>>>>>>> contains producers that inherit the qualifiers of the existing
>>>>> injection
>>>>>>>>> point.
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com>
>> wrote:
>>>>>>>>>
>>>>>>>>>> It's probably fair. They are certainly missing some things you
>> might
>>>>>>>>>> expect, that Antoine ran into…
>>>>>>>>>>
>>>>>>>>>> If we can find a way to create a similar extension capability but
>>>>>>>>>> implemented differently, it would be good. However what they offer
>>>>> is too
>>>>>>>>>> useful to pass up.
>>>>>>>>>>
>>>>>>>>>> You often have a situation where you want to create the effect of
>>>>> having a
>>>>>>>>>> group of beans for a multiple configurations of something.
>> Injection
>>>>> of
>>>>>>>>>> InjectionPoint can go some way to solving this, but suffers from
>>>>> three key
>>>>>>>>>> limitations. Let's first take an example problem domain which I
>> know
>>>>> well -
>>>>>>>>>> caches, specifically Infinispan.
>>>>>>>>>>
>>>>>>>>>> You obviously want to be able to configure multiple caches in an
>>>>>>>>>> application, as they might well have different characteristics,
>> such
>>>>> as
>>>>>>>>>> eviction policy, persistent storage, and so on.
>>>>>>>>>>
>>>>>>>>>> Infinispan offers a number of caching classes associated with a
>>>>> cache - a
>>>>>>>>>> Cache interface, and an AdvancedCache interface, as well as the
>>>>>>>>>> Configuration for the cache. We want to be able to inject any of
>>>>> these
>>>>>>>>>> objects for each cache configured. e.g.
>>>>>>>>>>
>>>>>>>>>> @Inject @Cache("cache1") Cache cache;
>>>>>>>>>> @Inject @Cache("cache1") AdvancedCache cache;
>>>>>>>>>> @Inject @Cache("cache1") Configuration cache;
>>>>>>>>>>
>>>>>>>>>> @Inject @Cache("cache2") Cache cache;
>>>>>>>>>> @Inject @Cache("cache2") AdvancedCache cache;
>>>>>>>>>> @Inject @Cache("cache2") Configuration cache;
>>>>>>>>>>
>>>>>>>>>> The first problem we can see here is that we've lost type safety.
>>>>> This is
>>>>>>>>>> quite easy to fix, simply by having the user create an annotation
>> per
>>>>>>>>>> cache, which perhaps could be meta-annotated with the name of
>> cache.
>>>>> We now
>>>>>>>>>> have (truncated for brevity!)
>>>>>>>>>>
>>>>>>>>>> @Inject @Cache1 Cache cache;
>>>>>>>>>>
>>>>>>>>>> However, now let's assume we are running in JavaSE, and we need to
>>>>> don't
>>>>>>>>>> have something like JNDI to look up the CacheManager in, every
>> time
>>>>> we want
>>>>>>>>>> to access a cache. We need to make the beans that hold the cache
>>>>> reference
>>>>>>>>>> application scoped. This is the first of the key problems I
>>>>> identified
>>>>>>>>>> above.
>>>>>>>>>>
>>>>>>>>>> We could solve this by saying that the cache manager is stored in
>>>>>>>>>> application scope, and the cache is looked up each time, but it's
>>>>> also
>>>>>>>>>> reasonable to assume that there can be multiple cache managers in
>> an
>>>>>>>>>> application.
>>>>>>>>>>
>>>>>>>>>> The second problem, is that we really still need a way to attach a
>>>>>>>>>> configuration to a cache. A producer method is an ideal way to do
>>>>> this
>>>>>>>>>> (produce the configuration needed for the cache, so that CDI can
>>>>> pass it to
>>>>>>>>>> Infinispan at the right point), but we somehow need to associate
>> this
>>>>>>>>>> producer method through, and have CDI know how to call this.
>>>>> Qualifiers of
>>>>>>>>>> course solve this.
>>>>>>>>>>
>>>>>>>>>> Finally, we of course want this properly validated at startup, and
>>>>> we do
>>>>>>>>>> know the entire system at startup.
>>>>>>>>>>
>>>>>>>>>> I hope that outlines some of the problems we wanted to solve with
>>>>> generic
>>>>>>>>>> beans. Anyone have a better idea how to solve this? I'm all ears
>> :-D
>>>>>>>>>>
>>>>>>>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>>>>>>>>
>>>>>>>>>>> I don't think it's correct to call them buggy. It's just that it
>>>>> might
>>>>>>>>>> be _very_ hard to provide the same behaviour over all our
>> supported
>>>>>>>>>> containers.
>>>>>>>>>>> But we will hit those kind of compat problems sooner or later
>>>>> anyway and
>>>>>>>>>> will need to find a way to deal with them.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> LieGrue,
>>>>>>>>>>> strub
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>>>> Cc:
>>>>>>>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>>>>>>>>
>>>>>>>>>>>> T hank you John to launch this subject. I've been very busy
>> since
>>>>>>>>>> january and
>>>>>>>>>>>> didn't found time to launch the subject. To be totally honest I
>>>>> thought
>>>>>>>>>> I
>>>>>>>>>>>> was the only one interested in them.
>>>>>>>>>>>>
>>>>>>>>>>>> Now regarding Generic beans in Solder :
>>>>>>>>>>>>
>>>>>>>>>>>> - documentation is quite inaccurate
>>>>>>>>>>>> - they are bugy : I didn't had bug, but it seems that some their
>>>>> tests
>>>>>>>>>>>> don't pass
>>>>>>>>>>>> - I read some wrong information about them : you can't create
>>>>> beans in
>>>>>>>>>>>> another scope that the generic bean definition.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll prepare a description of how I use them in Seam Social to
>> ease
>>>>>>>>>>>> extension of the framework and the issue I encounter using them.
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Antoine SABOT-DURAND
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> I think they're really powerful, but we may need to do some
>>>>> rewrite to
>>>>>>>>>>>> make sure it works correctly in a modular container.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would like to begin discussing the use of Generic Beans from
>>>>> Solder
>>>>>>>>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>>>>>>>>> bandwidth
>>>>>>>>>>>> and
>>>>>>>>>>>>>> offered to help him here). This feature is used to configure
>> a
>>>>> set of
>>>>>>>>>>>>>> related beans that require shared components, while still
>>>>> allowing
>>>>>>>>>>>> scopes
>>>>>>>>>>>>>> to be provided. This is useful when trying to make legacy
>>>>>>>>>>>> libraries/APIs
>>>>>>>>>>>>>> CDI capable. The following are the API components required
>> for
>>>>>>>>>>>>>> GenericBeans:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>>>>>>>>> configuration for the
>>>>>>>>>>>>>> generic. This annotation is placed on another annotation, as
>>>>> defined
>>>>>>>>>>>> by
>>>>>>>>>>>>>> the application developer or framework author to support how
>>>>>>>>>>>> configuration
>>>>>>>>>>>>>> is resolved. This will look for a matching bean of the given
>>>>> type and
>>>>>>>>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>>>>>>>>> - @Generic - when using the manager type, defines an expected
>>>>>>>>>> injection
>>>>>>>>>>>>>> point for a generic bean.
>>>>>>>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>>>>>>>>> relationship between
>>>>>>>>>>>>>> generic objects.
>>>>>>>>>>>>>> - @ApplyScope - indicates that the produced object should
>>>>> inherit the
>>>>>>>>>>>> scope
>>>>>>>>>>>>>> of the configuration.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The examples in the Solder documentation describe this in
>> depth:
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thoughts/questions on the feature?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> john
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Gerhard Petracek <ge...@gmail.com>.
@antoine:
i know - i was talking about using std. cdi mechanisms without introducing
a whole new approach in between.
however, for sure i'm ok with discussing this feature. we can have a look
at the current usage and possible alternatives.
maybe it's easier to start with the usage in infinispan.
@pete: it would be great, if you can describe the details.
regards,
gerhard
2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
> Gerahrd,
>
> I understand what you. Generic Beans are based on standard CDI as all
> extension we are doing in DS. Before using them I had a lot of extension
> to deal with my need. Generic Beans in seam social makes dev save about 50
> lines of oct for each OAuth Application declared(should it be only one for
> each SN, it's already more than 50). It's a great helper. I'm not sure of
> how the feature is used in Infinispan but it looks like the same need.
>
> CDI is strong typed and it's good but having a smart extension that can
> produce a bunch of bean with different scope and unknown qualifiers at
> compile time brings a dynamic aspect without forgetting the strong typed
> aspect.
>
> I'd be pleased if you have a look at Seam social[1] and see how they are
> used. So you could take half time to tell me how to do without them (but I
> already now, since I did without them before) and half time to see the
> potential of Generics.
>
> regards
>
>
> Antoine
> [1] http://github.com/seam/social
>
>
> Le 30 mars 2012 à 14:01, Pete Muir a écrit :
>
> > Hi Gerhard,
> >
> > Do you have some examples of configuring a "family of beans" in MyFaces
> CODI, where the family can be easily reused for different, coexisting,
> services? This would be very helpful so that we can see how CODI achieved
> this.
> >
> > pete
> >
> > On 30 Mar 2012, at 12:53, Gerhard Petracek wrote:
> >
> >> hi antoine,
> >>
> >> a lot of parts of myfaces codi are also customizable (easily) and almost
> >> all of them are based on std. cdi mechanisms.
> >>
> >> if the social module has special requirements, we can discuss the
> >> alternatives.
> >> if a std. based approach requires just a bit more effort to support new
> >> social services, it's ok imo because you don't have to do it that often.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
> >>
> >>> So what's next on "Bean Familiy Producer" ?
> >>>
> >>> They are used in infinispan cdi [1] and Seam Social [2].
> >>> In both case they are used to provide pug ability with unknown
> >>> implementation (I Can create a new Cache module with a new technology
> or I
> >>> can create a new Social Network Module for the last Twitter in town)
> >>>
> >>> So we agree it's mainly a framework development need to avoid users to
> >>> have to create a bunch of producers when they extend the framework.
> >>>
> >>> As it's used to produce beans they can be in different scope or merit
> >>> dynamically of master bean scope.
> >>>
> >>> To make it short : it seems rather useful even if the use cases are
> narrow.
> >>>
> >>> Does anybody have questions, objections ? Should we go for a vote ?
> >>>
> >>>
> >>> [1]
> >>>
> https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
> >>> [2]
> >>>
> https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
> >>>
> >>> Antoine SABOT-DURAND
> >>>
> >>>
> >>>
> >>> Le 9 mars 2012 à 17:32, Pete Muir a écrit :
> >>>
> >>>> I quite like Bean Family Producer actually.
> >>>>
> >>>> On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
> >>>>
> >>>>> What about "Bean Family" or "Bean Family Producer" ?
> >>>>>
> >>>>>
> >>>>> Antoine SABOT-DURAND
> >>>>>
> >>>>>
> >>>>> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
> >>>>>
> >>>>>> Yes, we need a new name for the feature, generic beans isn't good
> ;-)
> >>>>>>
> >>>>>> I'm not sure Bean Groups is right, any other ideas?
> >>>>>>
> >>>>>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
> >>>>>>
> >>>>>>> @pete
> >>>>>>>
> >>>>>>> Reminds me of the JMS issue we have.
> >>>>>>>
> >>>>>>> So I suppose - could we rename the feature - "Bean Groups" ? Then
> >>> describe
> >>>>>>> the feature more along the lines of "the ability to define a bean
> that
> >>>>>>> contains producers that inherit the qualifiers of the existing
> >>> injection
> >>>>>>> point.
> >>>>>>>
> >>>>>>> John
> >>>>>>>
> >>>>>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com>
> wrote:
> >>>>>>>
> >>>>>>>> It's probably fair. They are certainly missing some things you
> might
> >>>>>>>> expect, that Antoine ran into…
> >>>>>>>>
> >>>>>>>> If we can find a way to create a similar extension capability but
> >>>>>>>> implemented differently, it would be good. However what they offer
> >>> is too
> >>>>>>>> useful to pass up.
> >>>>>>>>
> >>>>>>>> You often have a situation where you want to create the effect of
> >>> having a
> >>>>>>>> group of beans for a multiple configurations of something.
> Injection
> >>> of
> >>>>>>>> InjectionPoint can go some way to solving this, but suffers from
> >>> three key
> >>>>>>>> limitations. Let's first take an example problem domain which I
> know
> >>> well -
> >>>>>>>> caches, specifically Infinispan.
> >>>>>>>>
> >>>>>>>> You obviously want to be able to configure multiple caches in an
> >>>>>>>> application, as they might well have different characteristics,
> such
> >>> as
> >>>>>>>> eviction policy, persistent storage, and so on.
> >>>>>>>>
> >>>>>>>> Infinispan offers a number of caching classes associated with a
> >>> cache - a
> >>>>>>>> Cache interface, and an AdvancedCache interface, as well as the
> >>>>>>>> Configuration for the cache. We want to be able to inject any of
> >>> these
> >>>>>>>> objects for each cache configured. e.g.
> >>>>>>>>
> >>>>>>>> @Inject @Cache("cache1") Cache cache;
> >>>>>>>> @Inject @Cache("cache1") AdvancedCache cache;
> >>>>>>>> @Inject @Cache("cache1") Configuration cache;
> >>>>>>>>
> >>>>>>>> @Inject @Cache("cache2") Cache cache;
> >>>>>>>> @Inject @Cache("cache2") AdvancedCache cache;
> >>>>>>>> @Inject @Cache("cache2") Configuration cache;
> >>>>>>>>
> >>>>>>>> The first problem we can see here is that we've lost type safety.
> >>> This is
> >>>>>>>> quite easy to fix, simply by having the user create an annotation
> per
> >>>>>>>> cache, which perhaps could be meta-annotated with the name of
> cache.
> >>> We now
> >>>>>>>> have (truncated for brevity!)
> >>>>>>>>
> >>>>>>>> @Inject @Cache1 Cache cache;
> >>>>>>>>
> >>>>>>>> However, now let's assume we are running in JavaSE, and we need to
> >>> don't
> >>>>>>>> have something like JNDI to look up the CacheManager in, every
> time
> >>> we want
> >>>>>>>> to access a cache. We need to make the beans that hold the cache
> >>> reference
> >>>>>>>> application scoped. This is the first of the key problems I
> >>> identified
> >>>>>>>> above.
> >>>>>>>>
> >>>>>>>> We could solve this by saying that the cache manager is stored in
> >>>>>>>> application scope, and the cache is looked up each time, but it's
> >>> also
> >>>>>>>> reasonable to assume that there can be multiple cache managers in
> an
> >>>>>>>> application.
> >>>>>>>>
> >>>>>>>> The second problem, is that we really still need a way to attach a
> >>>>>>>> configuration to a cache. A producer method is an ideal way to do
> >>> this
> >>>>>>>> (produce the configuration needed for the cache, so that CDI can
> >>> pass it to
> >>>>>>>> Infinispan at the right point), but we somehow need to associate
> this
> >>>>>>>> producer method through, and have CDI know how to call this.
> >>> Qualifiers of
> >>>>>>>> course solve this.
> >>>>>>>>
> >>>>>>>> Finally, we of course want this properly validated at startup, and
> >>> we do
> >>>>>>>> know the entire system at startup.
> >>>>>>>>
> >>>>>>>> I hope that outlines some of the problems we wanted to solve with
> >>> generic
> >>>>>>>> beans. Anyone have a better idea how to solve this? I'm all ears
> :-D
> >>>>>>>>
> >>>>>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
> >>>>>>>>
> >>>>>>>>> I don't think it's correct to call them buggy. It's just that it
> >>> might
> >>>>>>>> be _very_ hard to provide the same behaviour over all our
> supported
> >>>>>>>> containers.
> >>>>>>>>> But we will hit those kind of compat problems sooner or later
> >>> anyway and
> >>>>>>>> will need to find a way to deal with them.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> LieGrue,
> >>>>>>>>> strub
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
> >>>>>>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>>>>> Cc:
> >>>>>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
> >>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
> >>>>>>>>>>
> >>>>>>>>>> T hank you John to launch this subject. I've been very busy
> since
> >>>>>>>> january and
> >>>>>>>>>> didn't found time to launch the subject. To be totally honest I
> >>> thought
> >>>>>>>> I
> >>>>>>>>>> was the only one interested in them.
> >>>>>>>>>>
> >>>>>>>>>> Now regarding Generic beans in Solder :
> >>>>>>>>>>
> >>>>>>>>>> - documentation is quite inaccurate
> >>>>>>>>>> - they are bugy : I didn't had bug, but it seems that some their
> >>> tests
> >>>>>>>>>> don't pass
> >>>>>>>>>> - I read some wrong information about them : you can't create
> >>> beans in
> >>>>>>>>>> another scope that the generic bean definition.
> >>>>>>>>>>
> >>>>>>>>>> I'll prepare a description of how I use them in Seam Social to
> ease
> >>>>>>>>>> extension of the framework and the issue I encounter using them.
> >>>>>>>>>>
> >>>>>>>>>> regards,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Antoine SABOT-DURAND
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
> >>>>>>>>>>
> >>>>>>>>>>> I think they're really powerful, but we may need to do some
> >>> rewrite to
> >>>>>>>>>> make sure it works correctly in a modular container.
> >>>>>>>>>>>
> >>>>>>>>>>> Sent from my iPhone
> >>>>>>>>>>>
> >>>>>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
> >>>>>>>>>> <jo...@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi All
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would like to begin discussing the use of Generic Beans from
> >>> Solder
> >>>>>>>>>>>> (currently this issue is assigned to Antoine, but I have some
> >>>>>>>> bandwidth
> >>>>>>>>>> and
> >>>>>>>>>>>> offered to help him here). This feature is used to configure
> a
> >>> set of
> >>>>>>>>>>>> related beans that require shared components, while still
> >>> allowing
> >>>>>>>>>> scopes
> >>>>>>>>>>>> to be provided. This is useful when trying to make legacy
> >>>>>>>>>> libraries/APIs
> >>>>>>>>>>>> CDI capable. The following are the API components required
> for
> >>>>>>>>>>>> GenericBeans:
> >>>>>>>>>>>>
> >>>>>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
> >>>>>>>>>> configuration for the
> >>>>>>>>>>>> generic. This annotation is placed on another annotation, as
> >>> defined
> >>>>>>>>>> by
> >>>>>>>>>>>> the application developer or framework author to support how
> >>>>>>>>>> configuration
> >>>>>>>>>>>> is resolved. This will look for a matching bean of the given
> >>> type and
> >>>>>>>>>>>> resolve it based on the annotation that this is assigned to.
> >>>>>>>>>>>> - @Generic - when using the manager type, defines an expected
> >>>>>>>> injection
> >>>>>>>>>>>> point for a generic bean.
> >>>>>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
> >>>>>>>>>> relationship between
> >>>>>>>>>>>> generic objects.
> >>>>>>>>>>>> - @ApplyScope - indicates that the produced object should
> >>> inherit the
> >>>>>>>>>> scope
> >>>>>>>>>>>> of the configuration.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The examples in the Solder documentation describe this in
> depth:
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thoughts/questions on the feature?
> >>>>>>>>>>>>
> >>>>>>>>>>>> john
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
Gerahrd,
I understand what you. Generic Beans are based on standard CDI as all extension we are doing in DS. Before using them I had a lot of extension to deal with my need. Generic Beans in seam social makes dev save about 50 lines of oct for each OAuth Application declared(should it be only one for each SN, it's already more than 50). It's a great helper. I'm not sure of how the feature is used in Infinispan but it looks like the same need.
CDI is strong typed and it's good but having a smart extension that can produce a bunch of bean with different scope and unknown qualifiers at compile time brings a dynamic aspect without forgetting the strong typed aspect.
I'd be pleased if you have a look at Seam social[1] and see how they are used. So you could take half time to tell me how to do without them (but I already now, since I did without them before) and half time to see the potential of Generics.
regards
Antoine
[1] http://github.com/seam/social
Le 30 mars 2012 à 14:01, Pete Muir a écrit :
> Hi Gerhard,
>
> Do you have some examples of configuring a "family of beans" in MyFaces CODI, where the family can be easily reused for different, coexisting, services? This would be very helpful so that we can see how CODI achieved this.
>
> pete
>
> On 30 Mar 2012, at 12:53, Gerhard Petracek wrote:
>
>> hi antoine,
>>
>> a lot of parts of myfaces codi are also customizable (easily) and almost
>> all of them are based on std. cdi mechanisms.
>>
>> if the social module has special requirements, we can discuss the
>> alternatives.
>> if a std. based approach requires just a bit more effort to support new
>> social services, it's ok imo because you don't have to do it that often.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
>>
>>> So what's next on "Bean Familiy Producer" ?
>>>
>>> They are used in infinispan cdi [1] and Seam Social [2].
>>> In both case they are used to provide pug ability with unknown
>>> implementation (I Can create a new Cache module with a new technology or I
>>> can create a new Social Network Module for the last Twitter in town)
>>>
>>> So we agree it's mainly a framework development need to avoid users to
>>> have to create a bunch of producers when they extend the framework.
>>>
>>> As it's used to produce beans they can be in different scope or merit
>>> dynamically of master bean scope.
>>>
>>> To make it short : it seems rather useful even if the use cases are narrow.
>>>
>>> Does anybody have questions, objections ? Should we go for a vote ?
>>>
>>>
>>> [1]
>>> https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
>>> [2]
>>> https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
>>>
>>> Antoine SABOT-DURAND
>>>
>>>
>>>
>>> Le 9 mars 2012 à 17:32, Pete Muir a écrit :
>>>
>>>> I quite like Bean Family Producer actually.
>>>>
>>>> On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
>>>>
>>>>> What about "Bean Family" or "Bean Family Producer" ?
>>>>>
>>>>>
>>>>> Antoine SABOT-DURAND
>>>>>
>>>>>
>>>>> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
>>>>>
>>>>>> Yes, we need a new name for the feature, generic beans isn't good ;-)
>>>>>>
>>>>>> I'm not sure Bean Groups is right, any other ideas?
>>>>>>
>>>>>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>>>>>>
>>>>>>> @pete
>>>>>>>
>>>>>>> Reminds me of the JMS issue we have.
>>>>>>>
>>>>>>> So I suppose - could we rename the feature - "Bean Groups" ? Then
>>> describe
>>>>>>> the feature more along the lines of "the ability to define a bean that
>>>>>>> contains producers that inherit the qualifiers of the existing
>>> injection
>>>>>>> point.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>>>>>>>
>>>>>>>> It's probably fair. They are certainly missing some things you might
>>>>>>>> expect, that Antoine ran into…
>>>>>>>>
>>>>>>>> If we can find a way to create a similar extension capability but
>>>>>>>> implemented differently, it would be good. However what they offer
>>> is too
>>>>>>>> useful to pass up.
>>>>>>>>
>>>>>>>> You often have a situation where you want to create the effect of
>>> having a
>>>>>>>> group of beans for a multiple configurations of something. Injection
>>> of
>>>>>>>> InjectionPoint can go some way to solving this, but suffers from
>>> three key
>>>>>>>> limitations. Let's first take an example problem domain which I know
>>> well -
>>>>>>>> caches, specifically Infinispan.
>>>>>>>>
>>>>>>>> You obviously want to be able to configure multiple caches in an
>>>>>>>> application, as they might well have different characteristics, such
>>> as
>>>>>>>> eviction policy, persistent storage, and so on.
>>>>>>>>
>>>>>>>> Infinispan offers a number of caching classes associated with a
>>> cache - a
>>>>>>>> Cache interface, and an AdvancedCache interface, as well as the
>>>>>>>> Configuration for the cache. We want to be able to inject any of
>>> these
>>>>>>>> objects for each cache configured. e.g.
>>>>>>>>
>>>>>>>> @Inject @Cache("cache1") Cache cache;
>>>>>>>> @Inject @Cache("cache1") AdvancedCache cache;
>>>>>>>> @Inject @Cache("cache1") Configuration cache;
>>>>>>>>
>>>>>>>> @Inject @Cache("cache2") Cache cache;
>>>>>>>> @Inject @Cache("cache2") AdvancedCache cache;
>>>>>>>> @Inject @Cache("cache2") Configuration cache;
>>>>>>>>
>>>>>>>> The first problem we can see here is that we've lost type safety.
>>> This is
>>>>>>>> quite easy to fix, simply by having the user create an annotation per
>>>>>>>> cache, which perhaps could be meta-annotated with the name of cache.
>>> We now
>>>>>>>> have (truncated for brevity!)
>>>>>>>>
>>>>>>>> @Inject @Cache1 Cache cache;
>>>>>>>>
>>>>>>>> However, now let's assume we are running in JavaSE, and we need to
>>> don't
>>>>>>>> have something like JNDI to look up the CacheManager in, every time
>>> we want
>>>>>>>> to access a cache. We need to make the beans that hold the cache
>>> reference
>>>>>>>> application scoped. This is the first of the key problems I
>>> identified
>>>>>>>> above.
>>>>>>>>
>>>>>>>> We could solve this by saying that the cache manager is stored in
>>>>>>>> application scope, and the cache is looked up each time, but it's
>>> also
>>>>>>>> reasonable to assume that there can be multiple cache managers in an
>>>>>>>> application.
>>>>>>>>
>>>>>>>> The second problem, is that we really still need a way to attach a
>>>>>>>> configuration to a cache. A producer method is an ideal way to do
>>> this
>>>>>>>> (produce the configuration needed for the cache, so that CDI can
>>> pass it to
>>>>>>>> Infinispan at the right point), but we somehow need to associate this
>>>>>>>> producer method through, and have CDI know how to call this.
>>> Qualifiers of
>>>>>>>> course solve this.
>>>>>>>>
>>>>>>>> Finally, we of course want this properly validated at startup, and
>>> we do
>>>>>>>> know the entire system at startup.
>>>>>>>>
>>>>>>>> I hope that outlines some of the problems we wanted to solve with
>>> generic
>>>>>>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>>>>>>>
>>>>>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>>>>>>
>>>>>>>>> I don't think it's correct to call them buggy. It's just that it
>>> might
>>>>>>>> be _very_ hard to provide the same behaviour over all our supported
>>>>>>>> containers.
>>>>>>>>> But we will hit those kind of compat problems sooner or later
>>> anyway and
>>>>>>>> will need to find a way to deal with them.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>>> Cc:
>>>>>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>>>>>>
>>>>>>>>>> T hank you John to launch this subject. I've been very busy since
>>>>>>>> january and
>>>>>>>>>> didn't found time to launch the subject. To be totally honest I
>>> thought
>>>>>>>> I
>>>>>>>>>> was the only one interested in them.
>>>>>>>>>>
>>>>>>>>>> Now regarding Generic beans in Solder :
>>>>>>>>>>
>>>>>>>>>> - documentation is quite inaccurate
>>>>>>>>>> - they are bugy : I didn't had bug, but it seems that some their
>>> tests
>>>>>>>>>> don't pass
>>>>>>>>>> - I read some wrong information about them : you can't create
>>> beans in
>>>>>>>>>> another scope that the generic bean definition.
>>>>>>>>>>
>>>>>>>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>>>>>>>> extension of the framework and the issue I encounter using them.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Antoine SABOT-DURAND
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>>>>>>
>>>>>>>>>>> I think they're really powerful, but we may need to do some
>>> rewrite to
>>>>>>>>>> make sure it works correctly in a modular container.
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi All
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to begin discussing the use of Generic Beans from
>>> Solder
>>>>>>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>>>>>>> bandwidth
>>>>>>>>>> and
>>>>>>>>>>>> offered to help him here). This feature is used to configure a
>>> set of
>>>>>>>>>>>> related beans that require shared components, while still
>>> allowing
>>>>>>>>>> scopes
>>>>>>>>>>>> to be provided. This is useful when trying to make legacy
>>>>>>>>>> libraries/APIs
>>>>>>>>>>>> CDI capable. The following are the API components required for
>>>>>>>>>>>> GenericBeans:
>>>>>>>>>>>>
>>>>>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>>>>>>> configuration for the
>>>>>>>>>>>> generic. This annotation is placed on another annotation, as
>>> defined
>>>>>>>>>> by
>>>>>>>>>>>> the application developer or framework author to support how
>>>>>>>>>> configuration
>>>>>>>>>>>> is resolved. This will look for a matching bean of the given
>>> type and
>>>>>>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>>>>>>> - @Generic - when using the manager type, defines an expected
>>>>>>>> injection
>>>>>>>>>>>> point for a generic bean.
>>>>>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>>>>>>> relationship between
>>>>>>>>>>>> generic objects.
>>>>>>>>>>>> - @ApplyScope - indicates that the produced object should
>>> inherit the
>>>>>>>>>> scope
>>>>>>>>>>>> of the configuration.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts/questions on the feature?
>>>>>>>>>>>>
>>>>>>>>>>>> john
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Pete Muir <pm...@redhat.com>.
Hi Gerhard,
Do you have some examples of configuring a "family of beans" in MyFaces CODI, where the family can be easily reused for different, coexisting, services? This would be very helpful so that we can see how CODI achieved this.
pete
On 30 Mar 2012, at 12:53, Gerhard Petracek wrote:
> hi antoine,
>
> a lot of parts of myfaces codi are also customizable (easily) and almost
> all of them are based on std. cdi mechanisms.
>
> if the social module has special requirements, we can discuss the
> alternatives.
> if a std. based approach requires just a bit more effort to support new
> social services, it's ok imo because you don't have to do it that often.
>
> regards,
> gerhard
>
>
>
> 2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
>
>> So what's next on "Bean Familiy Producer" ?
>>
>> They are used in infinispan cdi [1] and Seam Social [2].
>> In both case they are used to provide pug ability with unknown
>> implementation (I Can create a new Cache module with a new technology or I
>> can create a new Social Network Module for the last Twitter in town)
>>
>> So we agree it's mainly a framework development need to avoid users to
>> have to create a bunch of producers when they extend the framework.
>>
>> As it's used to produce beans they can be in different scope or merit
>> dynamically of master bean scope.
>>
>> To make it short : it seems rather useful even if the use cases are narrow.
>>
>> Does anybody have questions, objections ? Should we go for a vote ?
>>
>>
>> [1]
>> https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
>> [2]
>> https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
>>
>> Antoine SABOT-DURAND
>>
>>
>>
>> Le 9 mars 2012 à 17:32, Pete Muir a écrit :
>>
>>> I quite like Bean Family Producer actually.
>>>
>>> On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
>>>
>>>> What about "Bean Family" or "Bean Family Producer" ?
>>>>
>>>>
>>>> Antoine SABOT-DURAND
>>>>
>>>>
>>>> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
>>>>
>>>>> Yes, we need a new name for the feature, generic beans isn't good ;-)
>>>>>
>>>>> I'm not sure Bean Groups is right, any other ideas?
>>>>>
>>>>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>>>>>
>>>>>> @pete
>>>>>>
>>>>>> Reminds me of the JMS issue we have.
>>>>>>
>>>>>> So I suppose - could we rename the feature - "Bean Groups" ? Then
>> describe
>>>>>> the feature more along the lines of "the ability to define a bean that
>>>>>> contains producers that inherit the qualifiers of the existing
>> injection
>>>>>> point.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>>>>>>
>>>>>>> It's probably fair. They are certainly missing some things you might
>>>>>>> expect, that Antoine ran into…
>>>>>>>
>>>>>>> If we can find a way to create a similar extension capability but
>>>>>>> implemented differently, it would be good. However what they offer
>> is too
>>>>>>> useful to pass up.
>>>>>>>
>>>>>>> You often have a situation where you want to create the effect of
>> having a
>>>>>>> group of beans for a multiple configurations of something. Injection
>> of
>>>>>>> InjectionPoint can go some way to solving this, but suffers from
>> three key
>>>>>>> limitations. Let's first take an example problem domain which I know
>> well -
>>>>>>> caches, specifically Infinispan.
>>>>>>>
>>>>>>> You obviously want to be able to configure multiple caches in an
>>>>>>> application, as they might well have different characteristics, such
>> as
>>>>>>> eviction policy, persistent storage, and so on.
>>>>>>>
>>>>>>> Infinispan offers a number of caching classes associated with a
>> cache - a
>>>>>>> Cache interface, and an AdvancedCache interface, as well as the
>>>>>>> Configuration for the cache. We want to be able to inject any of
>> these
>>>>>>> objects for each cache configured. e.g.
>>>>>>>
>>>>>>> @Inject @Cache("cache1") Cache cache;
>>>>>>> @Inject @Cache("cache1") AdvancedCache cache;
>>>>>>> @Inject @Cache("cache1") Configuration cache;
>>>>>>>
>>>>>>> @Inject @Cache("cache2") Cache cache;
>>>>>>> @Inject @Cache("cache2") AdvancedCache cache;
>>>>>>> @Inject @Cache("cache2") Configuration cache;
>>>>>>>
>>>>>>> The first problem we can see here is that we've lost type safety.
>> This is
>>>>>>> quite easy to fix, simply by having the user create an annotation per
>>>>>>> cache, which perhaps could be meta-annotated with the name of cache.
>> We now
>>>>>>> have (truncated for brevity!)
>>>>>>>
>>>>>>> @Inject @Cache1 Cache cache;
>>>>>>>
>>>>>>> However, now let's assume we are running in JavaSE, and we need to
>> don't
>>>>>>> have something like JNDI to look up the CacheManager in, every time
>> we want
>>>>>>> to access a cache. We need to make the beans that hold the cache
>> reference
>>>>>>> application scoped. This is the first of the key problems I
>> identified
>>>>>>> above.
>>>>>>>
>>>>>>> We could solve this by saying that the cache manager is stored in
>>>>>>> application scope, and the cache is looked up each time, but it's
>> also
>>>>>>> reasonable to assume that there can be multiple cache managers in an
>>>>>>> application.
>>>>>>>
>>>>>>> The second problem, is that we really still need a way to attach a
>>>>>>> configuration to a cache. A producer method is an ideal way to do
>> this
>>>>>>> (produce the configuration needed for the cache, so that CDI can
>> pass it to
>>>>>>> Infinispan at the right point), but we somehow need to associate this
>>>>>>> producer method through, and have CDI know how to call this.
>> Qualifiers of
>>>>>>> course solve this.
>>>>>>>
>>>>>>> Finally, we of course want this properly validated at startup, and
>> we do
>>>>>>> know the entire system at startup.
>>>>>>>
>>>>>>> I hope that outlines some of the problems we wanted to solve with
>> generic
>>>>>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>>>>>>
>>>>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>>>>>
>>>>>>>> I don't think it's correct to call them buggy. It's just that it
>> might
>>>>>>> be _very_ hard to provide the same behaviour over all our supported
>>>>>>> containers.
>>>>>>>> But we will hit those kind of compat problems sooner or later
>> anyway and
>>>>>>> will need to find a way to deal with them.
>>>>>>>>
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>>>> Cc:
>>>>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>>>>>
>>>>>>>>> T hank you John to launch this subject. I've been very busy since
>>>>>>> january and
>>>>>>>>> didn't found time to launch the subject. To be totally honest I
>> thought
>>>>>>> I
>>>>>>>>> was the only one interested in them.
>>>>>>>>>
>>>>>>>>> Now regarding Generic beans in Solder :
>>>>>>>>>
>>>>>>>>> - documentation is quite inaccurate
>>>>>>>>> - they are bugy : I didn't had bug, but it seems that some their
>> tests
>>>>>>>>> don't pass
>>>>>>>>> - I read some wrong information about them : you can't create
>> beans in
>>>>>>>>> another scope that the generic bean definition.
>>>>>>>>>
>>>>>>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>>>>>>> extension of the framework and the issue I encounter using them.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Antoine SABOT-DURAND
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>>>>>
>>>>>>>>>> I think they're really powerful, but we may need to do some
>> rewrite to
>>>>>>>>> make sure it works correctly in a modular container.
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All
>>>>>>>>>>>
>>>>>>>>>>> I would like to begin discussing the use of Generic Beans from
>> Solder
>>>>>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>>>>>> bandwidth
>>>>>>>>> and
>>>>>>>>>>> offered to help him here). This feature is used to configure a
>> set of
>>>>>>>>>>> related beans that require shared components, while still
>> allowing
>>>>>>>>> scopes
>>>>>>>>>>> to be provided. This is useful when trying to make legacy
>>>>>>>>> libraries/APIs
>>>>>>>>>>> CDI capable. The following are the API components required for
>>>>>>>>>>> GenericBeans:
>>>>>>>>>>>
>>>>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>>>>>> configuration for the
>>>>>>>>>>> generic. This annotation is placed on another annotation, as
>> defined
>>>>>>>>> by
>>>>>>>>>>> the application developer or framework author to support how
>>>>>>>>> configuration
>>>>>>>>>>> is resolved. This will look for a matching bean of the given
>> type and
>>>>>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>>>>>> - @Generic - when using the manager type, defines an expected
>>>>>>> injection
>>>>>>>>>>> point for a generic bean.
>>>>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>>>>>> relationship between
>>>>>>>>>>> generic objects.
>>>>>>>>>>> - @ApplyScope - indicates that the produced object should
>> inherit the
>>>>>>>>> scope
>>>>>>>>>>> of the configuration.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>>>>>
>>>>>>>>>>> Thoughts/questions on the feature?
>>>>>>>>>>>
>>>>>>>>>>> john
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Gerhard Petracek <ge...@gmail.com>.
hi antoine,
a lot of parts of myfaces codi are also customizable (easily) and almost
all of them are based on std. cdi mechanisms.
if the social module has special requirements, we can discuss the
alternatives.
if a std. based approach requires just a bit more effort to support new
social services, it's ok imo because you don't have to do it that often.
regards,
gerhard
2012/3/30 Antoine Sabot-Durand <an...@sabot-durand.net>
> So what's next on "Bean Familiy Producer" ?
>
> They are used in infinispan cdi [1] and Seam Social [2].
> In both case they are used to provide pug ability with unknown
> implementation (I Can create a new Cache module with a new technology or I
> can create a new Social Network Module for the last Twitter in town)
>
> So we agree it's mainly a framework development need to avoid users to
> have to create a bunch of producers when they extend the framework.
>
> As it's used to produce beans they can be in different scope or merit
> dynamically of master bean scope.
>
> To make it short : it seems rather useful even if the use cases are narrow.
>
> Does anybody have questions, objections ? Should we go for a vote ?
>
>
> [1]
> https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
> [2]
> https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
>
> Antoine SABOT-DURAND
>
>
>
> Le 9 mars 2012 à 17:32, Pete Muir a écrit :
>
> > I quite like Bean Family Producer actually.
> >
> > On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
> >
> >> What about "Bean Family" or "Bean Family Producer" ?
> >>
> >>
> >> Antoine SABOT-DURAND
> >>
> >>
> >> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
> >>
> >>> Yes, we need a new name for the feature, generic beans isn't good ;-)
> >>>
> >>> I'm not sure Bean Groups is right, any other ideas?
> >>>
> >>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
> >>>
> >>>> @pete
> >>>>
> >>>> Reminds me of the JMS issue we have.
> >>>>
> >>>> So I suppose - could we rename the feature - "Bean Groups" ? Then
> describe
> >>>> the feature more along the lines of "the ability to define a bean that
> >>>> contains producers that inherit the qualifiers of the existing
> injection
> >>>> point.
> >>>>
> >>>> John
> >>>>
> >>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
> >>>>
> >>>>> It's probably fair. They are certainly missing some things you might
> >>>>> expect, that Antoine ran into…
> >>>>>
> >>>>> If we can find a way to create a similar extension capability but
> >>>>> implemented differently, it would be good. However what they offer
> is too
> >>>>> useful to pass up.
> >>>>>
> >>>>> You often have a situation where you want to create the effect of
> having a
> >>>>> group of beans for a multiple configurations of something. Injection
> of
> >>>>> InjectionPoint can go some way to solving this, but suffers from
> three key
> >>>>> limitations. Let's first take an example problem domain which I know
> well -
> >>>>> caches, specifically Infinispan.
> >>>>>
> >>>>> You obviously want to be able to configure multiple caches in an
> >>>>> application, as they might well have different characteristics, such
> as
> >>>>> eviction policy, persistent storage, and so on.
> >>>>>
> >>>>> Infinispan offers a number of caching classes associated with a
> cache - a
> >>>>> Cache interface, and an AdvancedCache interface, as well as the
> >>>>> Configuration for the cache. We want to be able to inject any of
> these
> >>>>> objects for each cache configured. e.g.
> >>>>>
> >>>>> @Inject @Cache("cache1") Cache cache;
> >>>>> @Inject @Cache("cache1") AdvancedCache cache;
> >>>>> @Inject @Cache("cache1") Configuration cache;
> >>>>>
> >>>>> @Inject @Cache("cache2") Cache cache;
> >>>>> @Inject @Cache("cache2") AdvancedCache cache;
> >>>>> @Inject @Cache("cache2") Configuration cache;
> >>>>>
> >>>>> The first problem we can see here is that we've lost type safety.
> This is
> >>>>> quite easy to fix, simply by having the user create an annotation per
> >>>>> cache, which perhaps could be meta-annotated with the name of cache.
> We now
> >>>>> have (truncated for brevity!)
> >>>>>
> >>>>> @Inject @Cache1 Cache cache;
> >>>>>
> >>>>> However, now let's assume we are running in JavaSE, and we need to
> don't
> >>>>> have something like JNDI to look up the CacheManager in, every time
> we want
> >>>>> to access a cache. We need to make the beans that hold the cache
> reference
> >>>>> application scoped. This is the first of the key problems I
> identified
> >>>>> above.
> >>>>>
> >>>>> We could solve this by saying that the cache manager is stored in
> >>>>> application scope, and the cache is looked up each time, but it's
> also
> >>>>> reasonable to assume that there can be multiple cache managers in an
> >>>>> application.
> >>>>>
> >>>>> The second problem, is that we really still need a way to attach a
> >>>>> configuration to a cache. A producer method is an ideal way to do
> this
> >>>>> (produce the configuration needed for the cache, so that CDI can
> pass it to
> >>>>> Infinispan at the right point), but we somehow need to associate this
> >>>>> producer method through, and have CDI know how to call this.
> Qualifiers of
> >>>>> course solve this.
> >>>>>
> >>>>> Finally, we of course want this properly validated at startup, and
> we do
> >>>>> know the entire system at startup.
> >>>>>
> >>>>> I hope that outlines some of the problems we wanted to solve with
> generic
> >>>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
> >>>>>
> >>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
> >>>>>
> >>>>>> I don't think it's correct to call them buggy. It's just that it
> might
> >>>>> be _very_ hard to provide the same behaviour over all our supported
> >>>>> containers.
> >>>>>> But we will hit those kind of compat problems sooner or later
> anyway and
> >>>>> will need to find a way to deal with them.
> >>>>>>
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
> >>>>>>> To: deltaspike-dev@incubator.apache.org
> >>>>>>> Cc:
> >>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
> >>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
> >>>>>>>
> >>>>>>> T hank you John to launch this subject. I've been very busy since
> >>>>> january and
> >>>>>>> didn't found time to launch the subject. To be totally honest I
> thought
> >>>>> I
> >>>>>>> was the only one interested in them.
> >>>>>>>
> >>>>>>> Now regarding Generic beans in Solder :
> >>>>>>>
> >>>>>>> - documentation is quite inaccurate
> >>>>>>> - they are bugy : I didn't had bug, but it seems that some their
> tests
> >>>>>>> don't pass
> >>>>>>> - I read some wrong information about them : you can't create
> beans in
> >>>>>>> another scope that the generic bean definition.
> >>>>>>>
> >>>>>>> I'll prepare a description of how I use them in Seam Social to ease
> >>>>>>> extension of the framework and the issue I encounter using them.
> >>>>>>>
> >>>>>>> regards,
> >>>>>>>
> >>>>>>>
> >>>>>>> Antoine SABOT-DURAND
> >>>>>>>
> >>>>>>>
> >>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
> >>>>>>>
> >>>>>>>> I think they're really powerful, but we may need to do some
> rewrite to
> >>>>>>> make sure it works correctly in a modular container.
> >>>>>>>>
> >>>>>>>> Sent from my iPhone
> >>>>>>>>
> >>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
> >>>>>>> <jo...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hi All
> >>>>>>>>>
> >>>>>>>>> I would like to begin discussing the use of Generic Beans from
> Solder
> >>>>>>>>> (currently this issue is assigned to Antoine, but I have some
> >>>>> bandwidth
> >>>>>>> and
> >>>>>>>>> offered to help him here). This feature is used to configure a
> set of
> >>>>>>>>> related beans that require shared components, while still
> allowing
> >>>>>>> scopes
> >>>>>>>>> to be provided. This is useful when trying to make legacy
> >>>>>>> libraries/APIs
> >>>>>>>>> CDI capable. The following are the API components required for
> >>>>>>>>> GenericBeans:
> >>>>>>>>>
> >>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
> >>>>>>> configuration for the
> >>>>>>>>> generic. This annotation is placed on another annotation, as
> defined
> >>>>>>> by
> >>>>>>>>> the application developer or framework author to support how
> >>>>>>> configuration
> >>>>>>>>> is resolved. This will look for a matching bean of the given
> type and
> >>>>>>>>> resolve it based on the annotation that this is assigned to.
> >>>>>>>>> - @Generic - when using the manager type, defines an expected
> >>>>> injection
> >>>>>>>>> point for a generic bean.
> >>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
> >>>>>>> relationship between
> >>>>>>>>> generic objects.
> >>>>>>>>> - @ApplyScope - indicates that the produced object should
> inherit the
> >>>>>>> scope
> >>>>>>>>> of the configuration.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The examples in the Solder documentation describe this in depth:
> >>>>>>>>>
> >>>>>>>
> >>>>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
> >>>>>>>>>
> >>>>>>>>> Thoughts/questions on the feature?
> >>>>>>>>>
> >>>>>>>>> john
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
So what's next on "Bean Familiy Producer" ?
They are used in infinispan cdi [1] and Seam Social [2].
In both case they are used to provide pug ability with unknown implementation (I Can create a new Cache module with a new technology or I can create a new Social Network Module for the last Twitter in town)
So we agree it's mainly a framework development need to avoid users to have to create a bunch of producers when they extend the framework.
As it's used to produce beans they can be in different scope or merit dynamically of master bean scope.
To make it short : it seems rather useful even if the use cases are narrow.
Does anybody have questions, objections ? Should we go for a vote ?
[1] https://github.com/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
[2] https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
Antoine SABOT-DURAND
Le 9 mars 2012 à 17:32, Pete Muir a écrit :
> I quite like Bean Family Producer actually.
>
> On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
>
>> What about "Bean Family" or "Bean Family Producer" ?
>>
>>
>> Antoine SABOT-DURAND
>>
>>
>> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
>>
>>> Yes, we need a new name for the feature, generic beans isn't good ;-)
>>>
>>> I'm not sure Bean Groups is right, any other ideas?
>>>
>>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>>>
>>>> @pete
>>>>
>>>> Reminds me of the JMS issue we have.
>>>>
>>>> So I suppose - could we rename the feature - "Bean Groups" ? Then describe
>>>> the feature more along the lines of "the ability to define a bean that
>>>> contains producers that inherit the qualifiers of the existing injection
>>>> point.
>>>>
>>>> John
>>>>
>>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>>>>
>>>>> It's probably fair. They are certainly missing some things you might
>>>>> expect, that Antoine ran into…
>>>>>
>>>>> If we can find a way to create a similar extension capability but
>>>>> implemented differently, it would be good. However what they offer is too
>>>>> useful to pass up.
>>>>>
>>>>> You often have a situation where you want to create the effect of having a
>>>>> group of beans for a multiple configurations of something. Injection of
>>>>> InjectionPoint can go some way to solving this, but suffers from three key
>>>>> limitations. Let's first take an example problem domain which I know well -
>>>>> caches, specifically Infinispan.
>>>>>
>>>>> You obviously want to be able to configure multiple caches in an
>>>>> application, as they might well have different characteristics, such as
>>>>> eviction policy, persistent storage, and so on.
>>>>>
>>>>> Infinispan offers a number of caching classes associated with a cache - a
>>>>> Cache interface, and an AdvancedCache interface, as well as the
>>>>> Configuration for the cache. We want to be able to inject any of these
>>>>> objects for each cache configured. e.g.
>>>>>
>>>>> @Inject @Cache("cache1") Cache cache;
>>>>> @Inject @Cache("cache1") AdvancedCache cache;
>>>>> @Inject @Cache("cache1") Configuration cache;
>>>>>
>>>>> @Inject @Cache("cache2") Cache cache;
>>>>> @Inject @Cache("cache2") AdvancedCache cache;
>>>>> @Inject @Cache("cache2") Configuration cache;
>>>>>
>>>>> The first problem we can see here is that we've lost type safety. This is
>>>>> quite easy to fix, simply by having the user create an annotation per
>>>>> cache, which perhaps could be meta-annotated with the name of cache. We now
>>>>> have (truncated for brevity!)
>>>>>
>>>>> @Inject @Cache1 Cache cache;
>>>>>
>>>>> However, now let's assume we are running in JavaSE, and we need to don't
>>>>> have something like JNDI to look up the CacheManager in, every time we want
>>>>> to access a cache. We need to make the beans that hold the cache reference
>>>>> application scoped. This is the first of the key problems I identified
>>>>> above.
>>>>>
>>>>> We could solve this by saying that the cache manager is stored in
>>>>> application scope, and the cache is looked up each time, but it's also
>>>>> reasonable to assume that there can be multiple cache managers in an
>>>>> application.
>>>>>
>>>>> The second problem, is that we really still need a way to attach a
>>>>> configuration to a cache. A producer method is an ideal way to do this
>>>>> (produce the configuration needed for the cache, so that CDI can pass it to
>>>>> Infinispan at the right point), but we somehow need to associate this
>>>>> producer method through, and have CDI know how to call this. Qualifiers of
>>>>> course solve this.
>>>>>
>>>>> Finally, we of course want this properly validated at startup, and we do
>>>>> know the entire system at startup.
>>>>>
>>>>> I hope that outlines some of the problems we wanted to solve with generic
>>>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>>>>
>>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>>>
>>>>>> I don't think it's correct to call them buggy. It's just that it might
>>>>> be _very_ hard to provide the same behaviour over all our supported
>>>>> containers.
>>>>>> But we will hit those kind of compat problems sooner or later anyway and
>>>>> will need to find a way to deal with them.
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>>> Cc:
>>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>>>
>>>>>>> T hank you John to launch this subject. I've been very busy since
>>>>> january and
>>>>>>> didn't found time to launch the subject. To be totally honest I thought
>>>>> I
>>>>>>> was the only one interested in them.
>>>>>>>
>>>>>>> Now regarding Generic beans in Solder :
>>>>>>>
>>>>>>> - documentation is quite inaccurate
>>>>>>> - they are bugy : I didn't had bug, but it seems that some their tests
>>>>>>> don't pass
>>>>>>> - I read some wrong information about them : you can't create beans in
>>>>>>> another scope that the generic bean definition.
>>>>>>>
>>>>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>>>>> extension of the framework and the issue I encounter using them.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>>
>>>>>>> Antoine SABOT-DURAND
>>>>>>>
>>>>>>>
>>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>>>
>>>>>>>> I think they're really powerful, but we may need to do some rewrite to
>>>>>>> make sure it works correctly in a modular container.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi All
>>>>>>>>>
>>>>>>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>>>> bandwidth
>>>>>>> and
>>>>>>>>> offered to help him here). This feature is used to configure a set of
>>>>>>>>> related beans that require shared components, while still allowing
>>>>>>> scopes
>>>>>>>>> to be provided. This is useful when trying to make legacy
>>>>>>> libraries/APIs
>>>>>>>>> CDI capable. The following are the API components required for
>>>>>>>>> GenericBeans:
>>>>>>>>>
>>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>>>> configuration for the
>>>>>>>>> generic. This annotation is placed on another annotation, as defined
>>>>>>> by
>>>>>>>>> the application developer or framework author to support how
>>>>>>> configuration
>>>>>>>>> is resolved. This will look for a matching bean of the given type and
>>>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>>>> - @Generic - when using the manager type, defines an expected
>>>>> injection
>>>>>>>>> point for a generic bean.
>>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>>>> relationship between
>>>>>>>>> generic objects.
>>>>>>>>> - @ApplyScope - indicates that the produced object should inherit the
>>>>>>> scope
>>>>>>>>> of the configuration.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>>>>
>>>>>>>
>>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>>>
>>>>>>>>> Thoughts/questions on the feature?
>>>>>>>>>
>>>>>>>>> john
>>>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Pete Muir <pm...@redhat.com>.
I quite like Bean Family Producer actually.
On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
> What about "Bean Family" or "Bean Family Producer" ?
>
>
> Antoine SABOT-DURAND
>
>
> Le 7 mars 2012 à 16:55, Pete Muir a écrit :
>
>> Yes, we need a new name for the feature, generic beans isn't good ;-)
>>
>> I'm not sure Bean Groups is right, any other ideas?
>>
>> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>>
>>> @pete
>>>
>>> Reminds me of the JMS issue we have.
>>>
>>> So I suppose - could we rename the feature - "Bean Groups" ? Then describe
>>> the feature more along the lines of "the ability to define a bean that
>>> contains producers that inherit the qualifiers of the existing injection
>>> point.
>>>
>>> John
>>>
>>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>>>
>>>> It's probably fair. They are certainly missing some things you might
>>>> expect, that Antoine ran into…
>>>>
>>>> If we can find a way to create a similar extension capability but
>>>> implemented differently, it would be good. However what they offer is too
>>>> useful to pass up.
>>>>
>>>> You often have a situation where you want to create the effect of having a
>>>> group of beans for a multiple configurations of something. Injection of
>>>> InjectionPoint can go some way to solving this, but suffers from three key
>>>> limitations. Let's first take an example problem domain which I know well -
>>>> caches, specifically Infinispan.
>>>>
>>>> You obviously want to be able to configure multiple caches in an
>>>> application, as they might well have different characteristics, such as
>>>> eviction policy, persistent storage, and so on.
>>>>
>>>> Infinispan offers a number of caching classes associated with a cache - a
>>>> Cache interface, and an AdvancedCache interface, as well as the
>>>> Configuration for the cache. We want to be able to inject any of these
>>>> objects for each cache configured. e.g.
>>>>
>>>> @Inject @Cache("cache1") Cache cache;
>>>> @Inject @Cache("cache1") AdvancedCache cache;
>>>> @Inject @Cache("cache1") Configuration cache;
>>>>
>>>> @Inject @Cache("cache2") Cache cache;
>>>> @Inject @Cache("cache2") AdvancedCache cache;
>>>> @Inject @Cache("cache2") Configuration cache;
>>>>
>>>> The first problem we can see here is that we've lost type safety. This is
>>>> quite easy to fix, simply by having the user create an annotation per
>>>> cache, which perhaps could be meta-annotated with the name of cache. We now
>>>> have (truncated for brevity!)
>>>>
>>>> @Inject @Cache1 Cache cache;
>>>>
>>>> However, now let's assume we are running in JavaSE, and we need to don't
>>>> have something like JNDI to look up the CacheManager in, every time we want
>>>> to access a cache. We need to make the beans that hold the cache reference
>>>> application scoped. This is the first of the key problems I identified
>>>> above.
>>>>
>>>> We could solve this by saying that the cache manager is stored in
>>>> application scope, and the cache is looked up each time, but it's also
>>>> reasonable to assume that there can be multiple cache managers in an
>>>> application.
>>>>
>>>> The second problem, is that we really still need a way to attach a
>>>> configuration to a cache. A producer method is an ideal way to do this
>>>> (produce the configuration needed for the cache, so that CDI can pass it to
>>>> Infinispan at the right point), but we somehow need to associate this
>>>> producer method through, and have CDI know how to call this. Qualifiers of
>>>> course solve this.
>>>>
>>>> Finally, we of course want this properly validated at startup, and we do
>>>> know the entire system at startup.
>>>>
>>>> I hope that outlines some of the problems we wanted to solve with generic
>>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>>>
>>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>>
>>>>> I don't think it's correct to call them buggy. It's just that it might
>>>> be _very_ hard to provide the same behaviour over all our supported
>>>> containers.
>>>>> But we will hit those kind of compat problems sooner or later anyway and
>>>> will need to find a way to deal with them.
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>>> To: deltaspike-dev@incubator.apache.org
>>>>>> Cc:
>>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>>
>>>>>> T hank you John to launch this subject. I've been very busy since
>>>> january and
>>>>>> didn't found time to launch the subject. To be totally honest I thought
>>>> I
>>>>>> was the only one interested in them.
>>>>>>
>>>>>> Now regarding Generic beans in Solder :
>>>>>>
>>>>>> - documentation is quite inaccurate
>>>>>> - they are bugy : I didn't had bug, but it seems that some their tests
>>>>>> don't pass
>>>>>> - I read some wrong information about them : you can't create beans in
>>>>>> another scope that the generic bean definition.
>>>>>>
>>>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>>>> extension of the framework and the issue I encounter using them.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>>
>>>>>> Antoine SABOT-DURAND
>>>>>>
>>>>>>
>>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>>
>>>>>>> I think they're really powerful, but we may need to do some rewrite to
>>>>>> make sure it works correctly in a modular container.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>>> <jo...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi All
>>>>>>>>
>>>>>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>>> bandwidth
>>>>>> and
>>>>>>>> offered to help him here). This feature is used to configure a set of
>>>>>>>> related beans that require shared components, while still allowing
>>>>>> scopes
>>>>>>>> to be provided. This is useful when trying to make legacy
>>>>>> libraries/APIs
>>>>>>>> CDI capable. The following are the API components required for
>>>>>>>> GenericBeans:
>>>>>>>>
>>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>>> configuration for the
>>>>>>>> generic. This annotation is placed on another annotation, as defined
>>>>>> by
>>>>>>>> the application developer or framework author to support how
>>>>>> configuration
>>>>>>>> is resolved. This will look for a matching bean of the given type and
>>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>>> - @Generic - when using the manager type, defines an expected
>>>> injection
>>>>>>>> point for a generic bean.
>>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>>> relationship between
>>>>>>>> generic objects.
>>>>>>>> - @ApplyScope - indicates that the produced object should inherit the
>>>>>> scope
>>>>>>>> of the configuration.
>>>>>>>>
>>>>>>>>
>>>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>>>
>>>>>>
>>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>>
>>>>>>>> Thoughts/questions on the feature?
>>>>>>>>
>>>>>>>> john
>>>>>>
>>>>
>>>>
>>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
What about "Bean Family" or "Bean Family Producer" ?
Antoine SABOT-DURAND
Le 7 mars 2012 à 16:55, Pete Muir a écrit :
> Yes, we need a new name for the feature, generic beans isn't good ;-)
>
> I'm not sure Bean Groups is right, any other ideas?
>
> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>
>> @pete
>>
>> Reminds me of the JMS issue we have.
>>
>> So I suppose - could we rename the feature - "Bean Groups" ? Then describe
>> the feature more along the lines of "the ability to define a bean that
>> contains producers that inherit the qualifiers of the existing injection
>> point.
>>
>> John
>>
>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>>
>>> It's probably fair. They are certainly missing some things you might
>>> expect, that Antoine ran into…
>>>
>>> If we can find a way to create a similar extension capability but
>>> implemented differently, it would be good. However what they offer is too
>>> useful to pass up.
>>>
>>> You often have a situation where you want to create the effect of having a
>>> group of beans for a multiple configurations of something. Injection of
>>> InjectionPoint can go some way to solving this, but suffers from three key
>>> limitations. Let's first take an example problem domain which I know well -
>>> caches, specifically Infinispan.
>>>
>>> You obviously want to be able to configure multiple caches in an
>>> application, as they might well have different characteristics, such as
>>> eviction policy, persistent storage, and so on.
>>>
>>> Infinispan offers a number of caching classes associated with a cache - a
>>> Cache interface, and an AdvancedCache interface, as well as the
>>> Configuration for the cache. We want to be able to inject any of these
>>> objects for each cache configured. e.g.
>>>
>>> @Inject @Cache("cache1") Cache cache;
>>> @Inject @Cache("cache1") AdvancedCache cache;
>>> @Inject @Cache("cache1") Configuration cache;
>>>
>>> @Inject @Cache("cache2") Cache cache;
>>> @Inject @Cache("cache2") AdvancedCache cache;
>>> @Inject @Cache("cache2") Configuration cache;
>>>
>>> The first problem we can see here is that we've lost type safety. This is
>>> quite easy to fix, simply by having the user create an annotation per
>>> cache, which perhaps could be meta-annotated with the name of cache. We now
>>> have (truncated for brevity!)
>>>
>>> @Inject @Cache1 Cache cache;
>>>
>>> However, now let's assume we are running in JavaSE, and we need to don't
>>> have something like JNDI to look up the CacheManager in, every time we want
>>> to access a cache. We need to make the beans that hold the cache reference
>>> application scoped. This is the first of the key problems I identified
>>> above.
>>>
>>> We could solve this by saying that the cache manager is stored in
>>> application scope, and the cache is looked up each time, but it's also
>>> reasonable to assume that there can be multiple cache managers in an
>>> application.
>>>
>>> The second problem, is that we really still need a way to attach a
>>> configuration to a cache. A producer method is an ideal way to do this
>>> (produce the configuration needed for the cache, so that CDI can pass it to
>>> Infinispan at the right point), but we somehow need to associate this
>>> producer method through, and have CDI know how to call this. Qualifiers of
>>> course solve this.
>>>
>>> Finally, we of course want this properly validated at startup, and we do
>>> know the entire system at startup.
>>>
>>> I hope that outlines some of the problems we wanted to solve with generic
>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>>
>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>
>>>> I don't think it's correct to call them buggy. It's just that it might
>>> be _very_ hard to provide the same behaviour over all our supported
>>> containers.
>>>> But we will hit those kind of compat problems sooner or later anyway and
>>> will need to find a way to deal with them.
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>> To: deltaspike-dev@incubator.apache.org
>>>>> Cc:
>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>
>>>>> T hank you John to launch this subject. I've been very busy since
>>> january and
>>>>> didn't found time to launch the subject. To be totally honest I thought
>>> I
>>>>> was the only one interested in them.
>>>>>
>>>>> Now regarding Generic beans in Solder :
>>>>>
>>>>> - documentation is quite inaccurate
>>>>> - they are bugy : I didn't had bug, but it seems that some their tests
>>>>> don't pass
>>>>> - I read some wrong information about them : you can't create beans in
>>>>> another scope that the generic bean definition.
>>>>>
>>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>>> extension of the framework and the issue I encounter using them.
>>>>>
>>>>> regards,
>>>>>
>>>>>
>>>>> Antoine SABOT-DURAND
>>>>>
>>>>>
>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>
>>>>>> I think they're really powerful, but we may need to do some rewrite to
>>>>> make sure it works correctly in a modular container.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>> <jo...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi All
>>>>>>>
>>>>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>> bandwidth
>>>>> and
>>>>>>> offered to help him here). This feature is used to configure a set of
>>>>>>> related beans that require shared components, while still allowing
>>>>> scopes
>>>>>>> to be provided. This is useful when trying to make legacy
>>>>> libraries/APIs
>>>>>>> CDI capable. The following are the API components required for
>>>>>>> GenericBeans:
>>>>>>>
>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>> configuration for the
>>>>>>> generic. This annotation is placed on another annotation, as defined
>>>>> by
>>>>>>> the application developer or framework author to support how
>>>>> configuration
>>>>>>> is resolved. This will look for a matching bean of the given type and
>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>> - @Generic - when using the manager type, defines an expected
>>> injection
>>>>>>> point for a generic bean.
>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>> relationship between
>>>>>>> generic objects.
>>>>>>> - @ApplyScope - indicates that the produced object should inherit the
>>>>> scope
>>>>>>> of the configuration.
>>>>>>>
>>>>>>>
>>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>>
>>>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>
>>>>>>> Thoughts/questions on the feature?
>>>>>>>
>>>>>>> john
>>>>>
>>>
>>>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
You'll find below my feedback on Generic Beans in Seam Social (at last)
What I need is an easy way to create automatically a bunch of beans when a bean with a given annotation is declared (i.e. triggers implicit creation of associated beans). This solution make my task easier than declare a bunch of producer but also will ease the work of third party developers when they'll create a new module for a new Social Service.
In my OAuth use case I have a collection of beans created by the OAuthApplication generic annotation. This annotation has to be put on an OAuthService bean and contains information needed by all user to use this application (mainly consumer key and secret key).
The beans created the generic beans mechanism are
- an OAuthService with basic methods to deal with Oauth requests. It is Application Scoped.
- an OAuthserviceSettings which contains data about the the service (data retrieve from OAuthApplication annotation), it's also Application Scoped
- an OAuthProvider which contains low-level methods for OAuth encryption and hide the concrete implementation which today is a third party library : scribe-java. It's also application scoped
- an OAuthSession which contains data for a given user : OAuthToken and identity information cache. It's Session scoped.
So with this line of code :
@OAuthApplication(apiKey = "FQzlQC49UhvbMZoxUIvHTQ", apiSecret = "VQ5CZHG4qUoAkUUmckPn4iN4yyjBKcORTW0wnok4r1k")
@Twitter
@Produces
@ApplicationScoped
TwitterBaseService twitterService;
I create 4 beans with the @Twitter Qualifier and different scopes. When a 3rd party developer adds a new service, she has to create a new Qualifier (@LinkedIn for instance) a service bean managing calls to this service and that's all.
Now I had some issues with Generics. The main one is the documentation which is far from being up to date. I watched code and tests to figure out how it was suppose to run and I have to admit the code seems very complex (I'm not sure to figure out exactly how it does its magic). Last issue is more a CDI one but with Generics it becomes obvious : the difficulty for a bean to dynamically retrieve its qualifier(s) when its not in the depends scope (in that case @InjectionPoint does the job). To make short Generics would be better with more introspection tools for bean.
IMHO the concept behind Generics should be kept in DS but the implementation and usage should be simplified if possible.
regards,
Antoine
Le 7 mars 2012 à 16:55, Pete Muir a écrit :
> Yes, we need a new name for the feature, generic beans isn't good ;-)
>
> I'm not sure Bean Groups is right, any other ideas?
>
> On 7 Mar 2012, at 02:13, John D. Ament wrote:
>
>> @pete
>>
>> Reminds me of the JMS issue we have.
>>
>> So I suppose - could we rename the feature - "Bean Groups" ? Then describe
>> the feature more along the lines of "the ability to define a bean that
>> contains producers that inherit the qualifiers of the existing injection
>> point.
>>
>> John
>>
>> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>>
>>> It's probably fair. They are certainly missing some things you might
>>> expect, that Antoine ran into…
>>>
>>> If we can find a way to create a similar extension capability but
>>> implemented differently, it would be good. However what they offer is too
>>> useful to pass up.
>>>
>>> You often have a situation where you want to create the effect of having a
>>> group of beans for a multiple configurations of something. Injection of
>>> InjectionPoint can go some way to solving this, but suffers from three key
>>> limitations. Let's first take an example problem domain which I know well -
>>> caches, specifically Infinispan.
>>>
>>> You obviously want to be able to configure multiple caches in an
>>> application, as they might well have different characteristics, such as
>>> eviction policy, persistent storage, and so on.
>>>
>>> Infinispan offers a number of caching classes associated with a cache - a
>>> Cache interface, and an AdvancedCache interface, as well as the
>>> Configuration for the cache. We want to be able to inject any of these
>>> objects for each cache configured. e.g.
>>>
>>> @Inject @Cache("cache1") Cache cache;
>>> @Inject @Cache("cache1") AdvancedCache cache;
>>> @Inject @Cache("cache1") Configuration cache;
>>>
>>> @Inject @Cache("cache2") Cache cache;
>>> @Inject @Cache("cache2") AdvancedCache cache;
>>> @Inject @Cache("cache2") Configuration cache;
>>>
>>> The first problem we can see here is that we've lost type safety. This is
>>> quite easy to fix, simply by having the user create an annotation per
>>> cache, which perhaps could be meta-annotated with the name of cache. We now
>>> have (truncated for brevity!)
>>>
>>> @Inject @Cache1 Cache cache;
>>>
>>> However, now let's assume we are running in JavaSE, and we need to don't
>>> have something like JNDI to look up the CacheManager in, every time we want
>>> to access a cache. We need to make the beans that hold the cache reference
>>> application scoped. This is the first of the key problems I identified
>>> above.
>>>
>>> We could solve this by saying that the cache manager is stored in
>>> application scope, and the cache is looked up each time, but it's also
>>> reasonable to assume that there can be multiple cache managers in an
>>> application.
>>>
>>> The second problem, is that we really still need a way to attach a
>>> configuration to a cache. A producer method is an ideal way to do this
>>> (produce the configuration needed for the cache, so that CDI can pass it to
>>> Infinispan at the right point), but we somehow need to associate this
>>> producer method through, and have CDI know how to call this. Qualifiers of
>>> course solve this.
>>>
>>> Finally, we of course want this properly validated at startup, and we do
>>> know the entire system at startup.
>>>
>>> I hope that outlines some of the problems we wanted to solve with generic
>>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>>
>>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>>
>>>> I don't think it's correct to call them buggy. It's just that it might
>>> be _very_ hard to provide the same behaviour over all our supported
>>> containers.
>>>> But we will hit those kind of compat problems sooner or later anyway and
>>> will need to find a way to deal with them.
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>>> To: deltaspike-dev@incubator.apache.org
>>>>> Cc:
>>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>>
>>>>> T hank you John to launch this subject. I've been very busy since
>>> january and
>>>>> didn't found time to launch the subject. To be totally honest I thought
>>> I
>>>>> was the only one interested in them.
>>>>>
>>>>> Now regarding Generic beans in Solder :
>>>>>
>>>>> - documentation is quite inaccurate
>>>>> - they are bugy : I didn't had bug, but it seems that some their tests
>>>>> don't pass
>>>>> - I read some wrong information about them : you can't create beans in
>>>>> another scope that the generic bean definition.
>>>>>
>>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>>> extension of the framework and the issue I encounter using them.
>>>>>
>>>>> regards,
>>>>>
>>>>>
>>>>> Antoine SABOT-DURAND
>>>>>
>>>>>
>>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>>
>>>>>> I think they're really powerful, but we may need to do some rewrite to
>>>>> make sure it works correctly in a modular container.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>>> <jo...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi All
>>>>>>>
>>>>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>>>>> (currently this issue is assigned to Antoine, but I have some
>>> bandwidth
>>>>> and
>>>>>>> offered to help him here). This feature is used to configure a set of
>>>>>>> related beans that require shared components, while still allowing
>>>>> scopes
>>>>>>> to be provided. This is useful when trying to make legacy
>>>>> libraries/APIs
>>>>>>> CDI capable. The following are the API components required for
>>>>>>> GenericBeans:
>>>>>>>
>>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>>> configuration for the
>>>>>>> generic. This annotation is placed on another annotation, as defined
>>>>> by
>>>>>>> the application developer or framework author to support how
>>>>> configuration
>>>>>>> is resolved. This will look for a matching bean of the given type and
>>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>>> - @Generic - when using the manager type, defines an expected
>>> injection
>>>>>>> point for a generic bean.
>>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>>> relationship between
>>>>>>> generic objects.
>>>>>>> - @ApplyScope - indicates that the produced object should inherit the
>>>>> scope
>>>>>>> of the configuration.
>>>>>>>
>>>>>>>
>>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>>
>>>>>
>>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>>
>>>>>>> Thoughts/questions on the feature?
>>>>>>>
>>>>>>> john
>>>>>
>>>
>>>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Pete Muir <pm...@redhat.com>.
Yes, we need a new name for the feature, generic beans isn't good ;-)
I'm not sure Bean Groups is right, any other ideas?
On 7 Mar 2012, at 02:13, John D. Ament wrote:
> @pete
>
> Reminds me of the JMS issue we have.
>
> So I suppose - could we rename the feature - "Bean Groups" ? Then describe
> the feature more along the lines of "the ability to define a bean that
> contains producers that inherit the qualifiers of the existing injection
> point.
>
> John
>
> On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
>
>> It's probably fair. They are certainly missing some things you might
>> expect, that Antoine ran into…
>>
>> If we can find a way to create a similar extension capability but
>> implemented differently, it would be good. However what they offer is too
>> useful to pass up.
>>
>> You often have a situation where you want to create the effect of having a
>> group of beans for a multiple configurations of something. Injection of
>> InjectionPoint can go some way to solving this, but suffers from three key
>> limitations. Let's first take an example problem domain which I know well -
>> caches, specifically Infinispan.
>>
>> You obviously want to be able to configure multiple caches in an
>> application, as they might well have different characteristics, such as
>> eviction policy, persistent storage, and so on.
>>
>> Infinispan offers a number of caching classes associated with a cache - a
>> Cache interface, and an AdvancedCache interface, as well as the
>> Configuration for the cache. We want to be able to inject any of these
>> objects for each cache configured. e.g.
>>
>> @Inject @Cache("cache1") Cache cache;
>> @Inject @Cache("cache1") AdvancedCache cache;
>> @Inject @Cache("cache1") Configuration cache;
>>
>> @Inject @Cache("cache2") Cache cache;
>> @Inject @Cache("cache2") AdvancedCache cache;
>> @Inject @Cache("cache2") Configuration cache;
>>
>> The first problem we can see here is that we've lost type safety. This is
>> quite easy to fix, simply by having the user create an annotation per
>> cache, which perhaps could be meta-annotated with the name of cache. We now
>> have (truncated for brevity!)
>>
>> @Inject @Cache1 Cache cache;
>>
>> However, now let's assume we are running in JavaSE, and we need to don't
>> have something like JNDI to look up the CacheManager in, every time we want
>> to access a cache. We need to make the beans that hold the cache reference
>> application scoped. This is the first of the key problems I identified
>> above.
>>
>> We could solve this by saying that the cache manager is stored in
>> application scope, and the cache is looked up each time, but it's also
>> reasonable to assume that there can be multiple cache managers in an
>> application.
>>
>> The second problem, is that we really still need a way to attach a
>> configuration to a cache. A producer method is an ideal way to do this
>> (produce the configuration needed for the cache, so that CDI can pass it to
>> Infinispan at the right point), but we somehow need to associate this
>> producer method through, and have CDI know how to call this. Qualifiers of
>> course solve this.
>>
>> Finally, we of course want this properly validated at startup, and we do
>> know the entire system at startup.
>>
>> I hope that outlines some of the problems we wanted to solve with generic
>> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>>
>> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>>
>>> I don't think it's correct to call them buggy. It's just that it might
>> be _very_ hard to provide the same behaviour over all our supported
>> containers.
>>> But we will hit those kind of compat problems sooner or later anyway and
>> will need to find a way to deal with them.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>>>> To: deltaspike-dev@incubator.apache.org
>>>> Cc:
>>>> Sent: Sunday, March 4, 2012 8:38 PM
>>>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>>>
>>>> T hank you John to launch this subject. I've been very busy since
>> january and
>>>> didn't found time to launch the subject. To be totally honest I thought
>> I
>>>> was the only one interested in them.
>>>>
>>>> Now regarding Generic beans in Solder :
>>>>
>>>> - documentation is quite inaccurate
>>>> - they are bugy : I didn't had bug, but it seems that some their tests
>>>> don't pass
>>>> - I read some wrong information about them : you can't create beans in
>>>> another scope that the generic bean definition.
>>>>
>>>> I'll prepare a description of how I use them in Seam Social to ease
>>>> extension of the framework and the issue I encounter using them.
>>>>
>>>> regards,
>>>>
>>>>
>>>> Antoine SABOT-DURAND
>>>>
>>>>
>>>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>>>
>>>>> I think they're really powerful, but we may need to do some rewrite to
>>>> make sure it works correctly in a modular container.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>>>> <jo...@gmail.com> wrote:
>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>>>> (currently this issue is assigned to Antoine, but I have some
>> bandwidth
>>>> and
>>>>>> offered to help him here). This feature is used to configure a set of
>>>>>> related beans that require shared components, while still allowing
>>>> scopes
>>>>>> to be provided. This is useful when trying to make legacy
>>>> libraries/APIs
>>>>>> CDI capable. The following are the API components required for
>>>>>> GenericBeans:
>>>>>>
>>>>>> - @GenericType(Class<?> clazz) - defines the type of
>>>> configuration for the
>>>>>> generic. This annotation is placed on another annotation, as defined
>>>> by
>>>>>> the application developer or framework author to support how
>>>> configuration
>>>>>> is resolved. This will look for a matching bean of the given type and
>>>>>> resolve it based on the annotation that this is assigned to.
>>>>>> - @Generic - when using the manager type, defines an expected
>> injection
>>>>>> point for a generic bean.
>>>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>>>> relationship between
>>>>>> generic objects.
>>>>>> - @ApplyScope - indicates that the produced object should inherit the
>>>> scope
>>>>>> of the configuration.
>>>>>>
>>>>>>
>>>>>> The examples in the Solder documentation describe this in depth:
>>>>>>
>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>>>
>>>>>> Thoughts/questions on the feature?
>>>>>>
>>>>>> john
>>>>
>>
>>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by "John D. Ament" <jo...@gmail.com>.
@pete
Reminds me of the JMS issue we have.
So I suppose - could we rename the feature - "Bean Groups" ? Then describe
the feature more along the lines of "the ability to define a bean that
contains producers that inherit the qualifiers of the existing injection
point.
John
On Tue, Mar 6, 2012 at 5:47 AM, Pete Muir <pm...@redhat.com> wrote:
> It's probably fair. They are certainly missing some things you might
> expect, that Antoine ran into…
>
> If we can find a way to create a similar extension capability but
> implemented differently, it would be good. However what they offer is too
> useful to pass up.
>
> You often have a situation where you want to create the effect of having a
> group of beans for a multiple configurations of something. Injection of
> InjectionPoint can go some way to solving this, but suffers from three key
> limitations. Let's first take an example problem domain which I know well -
> caches, specifically Infinispan.
>
> You obviously want to be able to configure multiple caches in an
> application, as they might well have different characteristics, such as
> eviction policy, persistent storage, and so on.
>
> Infinispan offers a number of caching classes associated with a cache - a
> Cache interface, and an AdvancedCache interface, as well as the
> Configuration for the cache. We want to be able to inject any of these
> objects for each cache configured. e.g.
>
> @Inject @Cache("cache1") Cache cache;
> @Inject @Cache("cache1") AdvancedCache cache;
> @Inject @Cache("cache1") Configuration cache;
>
> @Inject @Cache("cache2") Cache cache;
> @Inject @Cache("cache2") AdvancedCache cache;
> @Inject @Cache("cache2") Configuration cache;
>
> The first problem we can see here is that we've lost type safety. This is
> quite easy to fix, simply by having the user create an annotation per
> cache, which perhaps could be meta-annotated with the name of cache. We now
> have (truncated for brevity!)
>
> @Inject @Cache1 Cache cache;
>
> However, now let's assume we are running in JavaSE, and we need to don't
> have something like JNDI to look up the CacheManager in, every time we want
> to access a cache. We need to make the beans that hold the cache reference
> application scoped. This is the first of the key problems I identified
> above.
>
> We could solve this by saying that the cache manager is stored in
> application scope, and the cache is looked up each time, but it's also
> reasonable to assume that there can be multiple cache managers in an
> application.
>
> The second problem, is that we really still need a way to attach a
> configuration to a cache. A producer method is an ideal way to do this
> (produce the configuration needed for the cache, so that CDI can pass it to
> Infinispan at the right point), but we somehow need to associate this
> producer method through, and have CDI know how to call this. Qualifiers of
> course solve this.
>
> Finally, we of course want this properly validated at startup, and we do
> know the entire system at startup.
>
> I hope that outlines some of the problems we wanted to solve with generic
> beans. Anyone have a better idea how to solve this? I'm all ears :-D
>
> On 4 Mar 2012, at 20:01, Mark Struberg wrote:
>
> > I don't think it's correct to call them buggy. It's just that it might
> be _very_ hard to provide the same behaviour over all our supported
> containers.
> > But we will hit those kind of compat problems sooner or later anyway and
> will need to find a way to deal with them.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Antoine Sabot-Durand <an...@sabot-durand.net>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Sunday, March 4, 2012 8:38 PM
> >> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
> >>
> >> T hank you John to launch this subject. I've been very busy since
> january and
> >> didn't found time to launch the subject. To be totally honest I thought
> I
> >> was the only one interested in them.
> >>
> >> Now regarding Generic beans in Solder :
> >>
> >> - documentation is quite inaccurate
> >> - they are bugy : I didn't had bug, but it seems that some their tests
> >> don't pass
> >> - I read some wrong information about them : you can't create beans in
> >> another scope that the generic bean definition.
> >>
> >> I'll prepare a description of how I use them in Seam Social to ease
> >> extension of the framework and the issue I encounter using them.
> >>
> >> regards,
> >>
> >>
> >> Antoine SABOT-DURAND
> >>
> >>
> >> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
> >>
> >>> I think they're really powerful, but we may need to do some rewrite to
> >> make sure it works correctly in a modular container.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> On Mar 4, 2012, at 8:52, "John D. Ament"
> >> <jo...@gmail.com> wrote:
> >>>
> >>>> Hi All
> >>>>
> >>>> I would like to begin discussing the use of Generic Beans from Solder
> >>>> (currently this issue is assigned to Antoine, but I have some
> bandwidth
> >> and
> >>>> offered to help him here). This feature is used to configure a set of
> >>>> related beans that require shared components, while still allowing
> >> scopes
> >>>> to be provided. This is useful when trying to make legacy
> >> libraries/APIs
> >>>> CDI capable. The following are the API components required for
> >>>> GenericBeans:
> >>>>
> >>>> - @GenericType(Class<?> clazz) - defines the type of
> >> configuration for the
> >>>> generic. This annotation is placed on another annotation, as defined
> >> by
> >>>> the application developer or framework author to support how
> >> configuration
> >>>> is resolved. This will look for a matching bean of the given type and
> >>>> resolve it based on the annotation that this is assigned to.
> >>>> - @Generic - when using the manager type, defines an expected
> injection
> >>>> point for a generic bean.
> >>>> - @GenericConfiguration(Class<?> clazz) - defines the
> >> relationship between
> >>>> generic objects.
> >>>> - @ApplyScope - indicates that the produced object should inherit the
> >> scope
> >>>> of the configuration.
> >>>>
> >>>>
> >>>> The examples in the Solder documentation describe this in depth:
> >>>>
> >>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
> >>>>
> >>>> Thoughts/questions on the feature?
> >>>>
> >>>> john
> >>
>
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Pete Muir <pm...@redhat.com>.
It's probably fair. They are certainly missing some things you might expect, that Antoine ran into…
If we can find a way to create a similar extension capability but implemented differently, it would be good. However what they offer is too useful to pass up.
You often have a situation where you want to create the effect of having a group of beans for a multiple configurations of something. Injection of InjectionPoint can go some way to solving this, but suffers from three key limitations. Let's first take an example problem domain which I know well - caches, specifically Infinispan.
You obviously want to be able to configure multiple caches in an application, as they might well have different characteristics, such as eviction policy, persistent storage, and so on.
Infinispan offers a number of caching classes associated with a cache - a Cache interface, and an AdvancedCache interface, as well as the Configuration for the cache. We want to be able to inject any of these objects for each cache configured. e.g.
@Inject @Cache("cache1") Cache cache;
@Inject @Cache("cache1") AdvancedCache cache;
@Inject @Cache("cache1") Configuration cache;
@Inject @Cache("cache2") Cache cache;
@Inject @Cache("cache2") AdvancedCache cache;
@Inject @Cache("cache2") Configuration cache;
The first problem we can see here is that we've lost type safety. This is quite easy to fix, simply by having the user create an annotation per cache, which perhaps could be meta-annotated with the name of cache. We now have (truncated for brevity!)
@Inject @Cache1 Cache cache;
However, now let's assume we are running in JavaSE, and we need to don't have something like JNDI to look up the CacheManager in, every time we want to access a cache. We need to make the beans that hold the cache reference application scoped. This is the first of the key problems I identified above.
We could solve this by saying that the cache manager is stored in application scope, and the cache is looked up each time, but it's also reasonable to assume that there can be multiple cache managers in an application.
The second problem, is that we really still need a way to attach a configuration to a cache. A producer method is an ideal way to do this (produce the configuration needed for the cache, so that CDI can pass it to Infinispan at the right point), but we somehow need to associate this producer method through, and have CDI know how to call this. Qualifiers of course solve this.
Finally, we of course want this properly validated at startup, and we do know the entire system at startup.
I hope that outlines some of the problems we wanted to solve with generic beans. Anyone have a better idea how to solve this? I'm all ears :-D
On 4 Mar 2012, at 20:01, Mark Struberg wrote:
> I don't think it's correct to call them buggy. It's just that it might be _very_ hard to provide the same behaviour over all our supported containers.
> But we will hit those kind of compat problems sooner or later anyway and will need to find a way to deal with them.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Antoine Sabot-Durand <an...@sabot-durand.net>
>> To: deltaspike-dev@incubator.apache.org
>> Cc:
>> Sent: Sunday, March 4, 2012 8:38 PM
>> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>>
>> T hank you John to launch this subject. I've been very busy since january and
>> didn't found time to launch the subject. To be totally honest I thought I
>> was the only one interested in them.
>>
>> Now regarding Generic beans in Solder :
>>
>> - documentation is quite inaccurate
>> - they are bugy : I didn't had bug, but it seems that some their tests
>> don't pass
>> - I read some wrong information about them : you can't create beans in
>> another scope that the generic bean definition.
>>
>> I'll prepare a description of how I use them in Seam Social to ease
>> extension of the framework and the issue I encounter using them.
>>
>> regards,
>>
>>
>> Antoine SABOT-DURAND
>>
>>
>> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>>
>>> I think they're really powerful, but we may need to do some rewrite to
>> make sure it works correctly in a modular container.
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 4, 2012, at 8:52, "John D. Ament"
>> <jo...@gmail.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> I would like to begin discussing the use of Generic Beans from Solder
>>>> (currently this issue is assigned to Antoine, but I have some bandwidth
>> and
>>>> offered to help him here). This feature is used to configure a set of
>>>> related beans that require shared components, while still allowing
>> scopes
>>>> to be provided. This is useful when trying to make legacy
>> libraries/APIs
>>>> CDI capable. The following are the API components required for
>>>> GenericBeans:
>>>>
>>>> - @GenericType(Class<?> clazz) - defines the type of
>> configuration for the
>>>> generic. This annotation is placed on another annotation, as defined
>> by
>>>> the application developer or framework author to support how
>> configuration
>>>> is resolved. This will look for a matching bean of the given type and
>>>> resolve it based on the annotation that this is assigned to.
>>>> - @Generic - when using the manager type, defines an expected injection
>>>> point for a generic bean.
>>>> - @GenericConfiguration(Class<?> clazz) - defines the
>> relationship between
>>>> generic objects.
>>>> - @ApplyScope - indicates that the produced object should inherit the
>> scope
>>>> of the configuration.
>>>>
>>>>
>>>> The examples in the Solder documentation describe this in depth:
>>>>
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>>
>>>> Thoughts/questions on the feature?
>>>>
>>>> john
>>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Mark Struberg <st...@yahoo.de>.
I don't think it's correct to call them buggy. It's just that it might be _very_ hard to provide the same behaviour over all our supported containers.
But we will hit those kind of compat problems sooner or later anyway and will need to find a way to deal with them.
LieGrue,
strub
----- Original Message -----
> From: Antoine Sabot-Durand <an...@sabot-durand.net>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Sunday, March 4, 2012 8:38 PM
> Subject: Re: [DISCUSS] DELTASPIKE-14 GenericBeans
>
>T hank you John to launch this subject. I've been very busy since january and
> didn't found time to launch the subject. To be totally honest I thought I
> was the only one interested in them.
>
> Now regarding Generic beans in Solder :
>
> - documentation is quite inaccurate
> - they are bugy : I didn't had bug, but it seems that some their tests
> don't pass
> - I read some wrong information about them : you can't create beans in
> another scope that the generic bean definition.
>
> I'll prepare a description of how I use them in Seam Social to ease
> extension of the framework and the issue I encounter using them.
>
> regards,
>
>
> Antoine SABOT-DURAND
>
>
> Le 4 mars 2012 à 18:27, Jason Porter a écrit :
>
>> I think they're really powerful, but we may need to do some rewrite to
> make sure it works correctly in a modular container.
>>
>> Sent from my iPhone
>>
>> On Mar 4, 2012, at 8:52, "John D. Ament"
> <jo...@gmail.com> wrote:
>>
>>> Hi All
>>>
>>> I would like to begin discussing the use of Generic Beans from Solder
>>> (currently this issue is assigned to Antoine, but I have some bandwidth
> and
>>> offered to help him here). This feature is used to configure a set of
>>> related beans that require shared components, while still allowing
> scopes
>>> to be provided. This is useful when trying to make legacy
> libraries/APIs
>>> CDI capable. The following are the API components required for
>>> GenericBeans:
>>>
>>> - @GenericType(Class<?> clazz) - defines the type of
> configuration for the
>>> generic. This annotation is placed on another annotation, as defined
> by
>>> the application developer or framework author to support how
> configuration
>>> is resolved. This will look for a matching bean of the given type and
>>> resolve it based on the annotation that this is assigned to.
>>> - @Generic - when using the manager type, defines an expected injection
>>> point for a generic bean.
>>> - @GenericConfiguration(Class<?> clazz) - defines the
> relationship between
>>> generic objects.
>>> - @ApplyScope - indicates that the produced object should inherit the
> scope
>>> of the configuration.
>>>
>>>
>>> The examples in the Solder documentation describe this in depth:
>>>
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>>
>>> Thoughts/questions on the feature?
>>>
>>> john
>
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Antoine Sabot-Durand <an...@sabot-durand.net>.
Thank you John to launch this subject. I've been very busy since january and didn't found time to launch the subject. To be totally honest I thought I was the only one interested in them.
Now regarding Generic beans in Solder :
- documentation is quite inaccurate
- they are bugy : I didn't had bug, but it seems that some their tests don't pass
- I read some wrong information about them : you can't create beans in another scope that the generic bean definition.
I'll prepare a description of how I use them in Seam Social to ease extension of the framework and the issue I encounter using them.
regards,
Antoine SABOT-DURAND
Le 4 mars 2012 à 18:27, Jason Porter a écrit :
> I think they're really powerful, but we may need to do some rewrite to make sure it works correctly in a modular container.
>
> Sent from my iPhone
>
> On Mar 4, 2012, at 8:52, "John D. Ament" <jo...@gmail.com> wrote:
>
>> Hi All
>>
>> I would like to begin discussing the use of Generic Beans from Solder
>> (currently this issue is assigned to Antoine, but I have some bandwidth and
>> offered to help him here). This feature is used to configure a set of
>> related beans that require shared components, while still allowing scopes
>> to be provided. This is useful when trying to make legacy libraries/APIs
>> CDI capable. The following are the API components required for
>> GenericBeans:
>>
>> - @GenericType(Class<?> clazz) - defines the type of configuration for the
>> generic. This annotation is placed on another annotation, as defined by
>> the application developer or framework author to support how configuration
>> is resolved. This will look for a matching bean of the given type and
>> resolve it based on the annotation that this is assigned to.
>> - @Generic - when using the manager type, defines an expected injection
>> point for a generic bean.
>> - @GenericConfiguration(Class<?> clazz) - defines the relationship between
>> generic objects.
>> - @ApplyScope - indicates that the produced object should inherit the scope
>> of the configuration.
>>
>>
>> The examples in the Solder documentation describe this in depth:
>> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>>
>> Thoughts/questions on the feature?
>>
>> john
Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Posted by Jason Porter <li...@gmail.com>.
I think they're really powerful, but we may need to do some rewrite to make sure it works correctly in a modular container.
Sent from my iPhone
On Mar 4, 2012, at 8:52, "John D. Ament" <jo...@gmail.com> wrote:
> Hi All
>
> I would like to begin discussing the use of Generic Beans from Solder
> (currently this issue is assigned to Antoine, but I have some bandwidth and
> offered to help him here). This feature is used to configure a set of
> related beans that require shared components, while still allowing scopes
> to be provided. This is useful when trying to make legacy libraries/APIs
> CDI capable. The following are the API components required for
> GenericBeans:
>
> - @GenericType(Class<?> clazz) - defines the type of configuration for the
> generic. This annotation is placed on another annotation, as defined by
> the application developer or framework author to support how configuration
> is resolved. This will look for a matching bean of the given type and
> resolve it based on the annotation that this is assigned to.
> - @Generic - when using the manager type, defines an expected injection
> point for a generic bean.
> - @GenericConfiguration(Class<?> clazz) - defines the relationship between
> generic objects.
> - @ApplyScope - indicates that the produced object should inherit the scope
> of the configuration.
>
>
> The examples in the Solder documentation describe this in depth:
> http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/solder-genericbeans.html
>
> Thoughts/questions on the feature?
>
> john