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 <[email protected]> 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 <[email protected]> >>>>>> To: [email protected] >>>>>> 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" >>>>>> <[email protected]> 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 >>>>>> >>>> >>>> >> >
