deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Sabot-Durand <anto...@sabot-durand.net>
Subject Re: [DISCUSS] DELTASPIKE-14 GenericBeans
Date Fri, 09 Mar 2012 08:54:37 GMT
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 <pmuir@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 <antoine@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"
>>>>> <john.d.ament@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
>>>>> 
>>> 
>>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message